Video demos of Huron - Access and the SQL Server Data Services

desejo estudar informatica o access xp 2003

There's a lot of good info in those videos. Huron does look promising and seems pretty far along. I never imagined that MS would have enabled Access-SDS so quickly - thank you. I'm not sure how well huron matches what I was hoping MS would come up with to tie in Access to SDS, because it's so synchronization-based. I had hoped that Access might be able to work with SDS in more a smart client manner; like local .net winforms tapping in remote data via web services or remoting (think strataframe, ideablade/devforce). I wonder how well the sychronization will work, ie how disconnected the application will feel? Replication/synchronization has never been the most appealing approach for what I do. But if it works well, I could adjust. Currently I do the best I can with Access as a fat client tapping remote data sources with a mix of odbc, sql passthrough queries and ado for some applications. Obviously there are a lot of issues that come with that approach, and using Terminal Services is better for a lot of situations. Most of what I do these days uses sql server with an Access front end. I am not clear how that fits into the huron approach. SDS is based on sql server so ultimately the data store is sql server and that's good. As far as what type of data store is use when data is replicated to the local workstation, and then updated, and which provides data for back to SDS, I suppose with huron it does not matter so much? A local accdb is not likely to corrupt, because it's being used as originally intended, locally, not stretched over a long wire. It would have been interesting to include a segment that deals with edit conflicts, one user has deleted a record that another has edited, or simple concurrent edit conflicts. I am not sure if the videos make it clear how the automatic synch handles data changes. Auto synch can be set to periodically refresh, ok. But can it be set to update as needed? Say you load an invoice, which had 10 line items when you viewed it a few minutes ago, but now in the cloud has 14 line items via another user? I'd want to see the 14 line items, I'd want to *know* that what I was looking at was current, not what was true five minutes ago. For that matter does huron send only requested data to the client, when the amount of data in the cloud is non-trivial? What does huron do if the Customer table has 100,000 rows, or 1M, and you start making requests to load some of that data? Surely the full set is not replicated to the client, and then queried? Overall, huron is a most interesting wave to appear in the Access world, especially since it's arriving a year or two before I expected it.

This looks really exciting and I can see some of my customers wanting this. A couple of questions:

1) Will it be possible to sync just the back end of a normal split front end / back end system? If an organisation already has a system with, say, 5 front ends working with a back end on a server, they may want to synchronise just the back end with an off-site laptop user rather than have to have all the data on all 6 machines.

2) The video explained that it will be possible to enable just some of the tables for synchronisation, but will it be possible to synchronise just a subset of the data in any particular table as you used to be able to do with the old Jet synchronisation? Alan

I will like to know the difference of using this new technology or using actual linked tables to a SQL server. Will this be like using a disconected recordset, a local table, like turn up my computer in an airplane, making some changes and then synch them when im on the office. Is this is what we are talking about, this is a great oportunity for access developers, and definetly i want to hear more about this. can you guys send us some samples, where we can do our changes, and sycnh the changes back to your server, that will be great to see, and of course so that i can see the changes done by other users.

Michaels, First of all thanks for the comment at the end. I am really glad to hear your feedback on this. To your comment about conflict handling. Right now we are doing a server wins mode of conflict handling, however I am not sure I feel we have a good handle on the best way to automate conflict handling and this will be a primary focus of the early adopter program. In my head we want to make conflict handling as straightforward as Outlook where the user is not bothered with conflicts but can view and handle them where they want. Certainly because we base this on Sync Framework we can choose and conflict resolution model we like but it is still to be seen what the consensus will be on this. For the sync as needed functionality my expectation is that we will need some sort of trigger mechanism in the client database. Certainly this will be easy with a database like SQL Server but might be a little harder in other databases like SQL Compact and Access unless we build the logic in the Huron client. Certainly that would be possible but I doubt it will make it in the first version. - Liam

For your last question, I think you are referring to filtering of data, correct? So that if you have 1M rows you can choose to subscribe to certain amounts of data to limit the initial data download. Yes, this is functionality that we plan to add to Huron.

Alan, To your questions: 1) Yes, synchronization of just the back-end database will be possible. However, I think you will find that there are actual advantages to have the user data locally accessible. For example if you look at Outlook, you always work from a local Outlook email store and sync to the Exchange server happens in the background. This makes it so if the network gets slow (or disconnects) the user does not see a difference. 2) Yes, subsetting of data will be possible. - Liam

Edwin, Yes, this is different than linked tables as you do have a local set of data to work with and change. You airplane example is a great summary of a reason why this can be so useful. As you take the information with you, you can update it and the send the changes up to your database once connectivity is brought back online. - Liam

Hi Liam It will be interesting to see how the trigger side gets worked out. For many of the Access devs here, sql server is maybe the preferred backend for their Access apps already (rather than mdb or accdb). So a solution involving sql server on the client side, for them at least, would not present itself as a barrier. But I'm sure you want to offer the most monolithic solution that you can, not one that varies according to whatever is on the client side. One might guess that for devs that care about this issue (making sure that the most current data is presented to the user), one would be able to make a synch request programmatically (vba) as seems needed. As long as that's doable I'd guess it'd be sufficient. Since the synch op has got to take some time, one guess that a programmatic solution that would not drag down performance too much would work like: present data as it's stored locally; test for updates to the relevent data programatically in the background; and only resynch the displayed data if the test found a need for it. Anyways, it's got to be a complex and interesting topic to explore, how to rely on the local data while quietly testing for the need to synch. For non-programmer Access users that rely on huron to tap data in SDS, maybe it won't be so crucial to them? Re the last question, I'm not sure you have had a lot of exposure to Access development. I was describing a typical master detail form layout, where invoice info is show at the top of the form, and a subform is used to display multiple rows of related data, the invoice line items. After a night's sleep it suppose it's rather obvious that the synch model presupposes that the local datastore is kept in synch with the cloud data store; so the request for invoice details would be serviced by the local data store, and not ref the cloud data directly at all. So I think my question was just 'wrong', it reflected my vision about SDS-Access from before exposure to huron; tapping into SDS data directly from Access. I'd like to ask you about one thing that an attendee brought up to you at the conference, which I don't was responded to fully. He asked something like "does huron mean that all data would have to be replicated to the client"? The implication being that with substantial data the original synch could be a pretty long winded process. I understood your response to be more about the one time original synch from a local db to the cloud, at the start of the move to SDS storage. I'd be more concerned with the need to download a massive amount of data to each client; would that be required for the client to use the synch'd, local data store? Maybe I just misunderstood your reply. I did hear you say that one could synch or not synch on a table by table basis, and to Alan above you said synch'ing a subset of data would be possible...that's a good sign. I'm not positive that you understood the #1 that Alan asked you...sorry if you did but let me try to explain what I think he meant. In a typical developer level Access-sql server deployment, there is sql server backend on the LAN (or even WAN) which is accessed and updated by Access apps installed on user's workstations. In an Access-SQL setup like that, the data is never stored on the client workstations, it's on single instance of sql server. He wants to know (I think) if that sql server can be synch'd to the cloud independent of the Access clients, rather than have a copy of the synch'd data on each workstation. I'd imagine that the answer is yes.

Michaels,

With regard to the answer to #1, Liam did answer OK as I was thinking of a totally Access-based solution. As he says, normal operations will work more quickly if the data is on the local PC. It would also mean a simpler architecture for a database, i.e. no need for relinking code and stuff like that. It would just mean putting the split database back into one database again. As MS will still give us the option to a back end sync if we want it then we should be laughing. I see you point on the use of SQL Server back end though. Liam,

Glad to hear about #2. Thanks. Alan

Liam . . . Thanks for your explanation, so back again to my airplane example. What is now the difference now between holding a sql db in my laptop and entering data, and when i go back to the office, replicate with the server. Now both will be in synch, of course this is replication. So, with this new technology, replication will be extended to access database, so after i entered information in my access database, now when i use the synch framework, will synch my access database and the sql database. is this correct?

will this cork with sql 2008 only,or also sql 2005. Edwin

Yes and no. You are correct that there are sync technologies that allow you to come back to your office and replicate directly to the server. With "Huron", however, you always sync with the cloud. In your case, your airplane user would sync data to the cloud and then the enterprise data store (if there was one) would talk to the cloud and bring the changes back in. I consider the solutions you are talking about to be "on premises" which means that you as an organization manage the sync infrastucture, scalability, security etc and users sync directly to an enterprise data store. In our group we have technologies like Sync Services for ADO.NET that do just that. I don't want to downplay this as a viable option but what "Huron" is going after is the simplification (is that a word?) of synchronization. What we are doing is moving all of the complexities of sync out to the cloud (scalability, security, availability, etc) so that you as a user can simply publish and subscribe to the data in the cloud. For businesses that do not have an enterprise database this can be especially attractive as it gives them a point to securely consolidate and share data. However, for large enterprises this can also be attractive because any user can choose to publish data to the cloud without working with I.T. to set up a firewall or security mechanisms. It allows them to test the waters with sync in a very easy manner. Certainly down the road, the organization may choose to bring this in house to manage the sync infrastructure on-premises but our hope with "Huron" is that they will also see the value of having data in the cloud to allow them to also take advantage of the new cloud services coming such as reporting. I hope that makes sense. Liam

Liam thanks for the background info on what the huron project is about. It has made it more clear for me, at least. Your hopes for huron seem realistic, from my perspective. Too I hope that huron can help improve the influence that Access devs have with the MS Access team. I say that because most Access devs don't feel that the product has been taken in the right direction with A2007. If Access becomes a great client for huron/SDS, Microsoft would be making money from every successful Access deployment with huron as a backend. That ought to translate into an improved Access runtime, and more attention to the features developer want. I say that because the easier Microsoft makes it to deploy robust applications, the more 'subscribers' to the data side. At least that's what I come up with.