We get questions from users asking how they can build client server solutions using VistaDB, or more often just how they can avoid having to share drive letters to share a database. My traditional answer in the past has been to build a simple data access layer (DAL) and expose it over SOAP or WCF. Now with ADO.NET Data Services and our Entity Framework (EF) provider you have another choice.
ADO.NET Data Services (Astoria)
Not familiar with the codename? “Project Astoria” was released with .Net 3.5 SP1 under the moniker ADO.NET Data Services. This services on the surface appears to be about putting generic objects in front of your data and letting it handle protocols for you. The fact that you can take any EF model (VistaDB included) and put an ADO.Net Data Service around it in a controlled manner is fantastic. No more need needing to handle the shared drive scenario. You connect to a service hub, and that hub then applies all the changes and takes care of the ugly handling of edge cases. This is similar to a feature that allowed direct from within SQL Server, but I think too many DBA’s didn’t want to expose their actual SQL Server. Push all that exposure out to IIS and you have the same basic functions.
When is it available?
ADO.NET Data Services is .Net 3.5 SP1 technology and is considered production code. Today you can easily create a service that runs on one local machine and all clients point to it for their data. This single server allows all others to make queries against it without concern for direct access to the database.
What if the service is unavailable?
ADO.NET Data Services requires online access to the service. If the service goes down, the clients can’t do much. There is an offline version of Astoria in the works from Microsoft to allow a local client proxy to build up and sync to the service endpoint. I have watched a few PDC demos on it and it looks impressive, but it is still in the Alpha stages at the time of this writing. I tried to play around with it a little and it was almost all still hard coded to SQL Server and SQL CE.
Even without the offline version of Astoria I think you could build a highly reliable system using just the ADO.NET Data Services. Your client would have to be intelligent enough to know what to do in a failure to connect scenario, but this is no different than a client server database application today. The client still has to handle what happens when the server goes away.
Take an intranet site and add a client component
A sample scenario we just recently deployed on the intranet could expand to work over the internet. We could easily build a client timesheet app (copy local or click once) that knows how to get data through the service rather than direct from the database, and perform the data presentation within that client.

Sample Scenario
We have an existing website that users use to input their time spent daily, and weekly submit the timesheet. At the end of time period someone needs to collect the timesheets, approve and pay the correct employees.
ASP.NET Intranet Site
We already have a system that does this all through ASP.Net for the intranet users. But what if one user needed to work remotely? We could enable the intranet to be accessed remotely, or we could just expose the service and implement security to prevent unauthorized access. Using a click once application for the user approving the timesheets would enable her to work in the office or at home when approving and paying the timesheets without her having to know the difference.
Multiple Ways to get at your data
For this particular scenario we decided to leave the intranet alone for the employees. It works and they know how to use it. But the person approving the timesheets right now has to come into the office in order to approve them. She is not very technical and setting up a VPN would be serious overkill for this simple application.
Works with VistaDB today!
Yes, ADO.NET Data Services work with VistaDB 4 today through the EF provider. We don’t have any samples built specifically around this technology though (hence why this post).
Good sample?
Would this be a sample you would be interested in seeing built? Would you be interested in seeing how to build and deploy an ADO.NET Data Service using VistaDB?
We have the current Timesheet sample that is a simplified version of our timesheet system. I thought if we were going to build this local and remote application for our accountant that others might like to see how it is done as well. I think it makes a very easy scenario to get access to VistaDB database remotely without a lot of custom programming on the developers end. There is not a lot to know about the communications layer, but it could surely be customized for many deployment scenarios.