Svideo (21) [Avatar] Offline
#1
I bought the upgrade to Visual Studio 2008 wanting to use Linq to SQL heavily. It seems it that access data bases are not supported and I found the reason. Unfortunately no one is going to buy Server 2005 at 700$ to buy my 99$ product. Is there any solution to use linq on local databases with out having to run a server and being able to load and save access database files.
Lee Dumond (29) [Avatar] Offline
#2
Re: access .mdb databases
It works fine with SQL Server Express, which is totally free (and also redistributable).
Svideo (21) [Avatar] Offline
#3
Re: access .mdb databases
But it doesnt't take .mdb files natively and I'm not keen on supporting a database server that will take 10 times more technical support than my application.

I need to keep this real simple. From looking around I think I'm on board with forcing the renaming of Linq to SQL to Linq to SQL_Server. That is unless someone comes up with an answer to loading access files.
jwooley (123) [Avatar] Offline
#4
Re: access .mdb databases
Don't expect LINQ to SQL to support Access. That would be LINQ to Access. Actually, the Entity Framework should support access, so that may be your solution if you require access for your database.

As another alternative, you might want to consider using Sql Server Compact Edition. The LINQ to SQL designer does not work at the moment against SQLCE, but the framework does support it. This is a fairly light-weight alternative data store that you will be seeing more and more of in the future.

Jim
Svideo (21) [Avatar] Offline
#5
Re: access .mdb databases
I did try looking at the sql server compact version but a lot of the tools don't work and wont install on x64. Maybe another 6 months. Also I checked and I don't see web hosts really supporting compact, most didn't know what it was.

The main point is to allow one file updates of websites with out buying SQL server and using replication etc.

>>The SSCE type system is a subset of the SQL Server 2005 type system, and does not support all features that a full SQL Server instance supports. Commonly used features from SQL Server for server applications that are not present in SSCE include stored procedures, triggers, views, functions, user defined data types, and the ability to participate in SQL Server Service Broker messaging.

Not that I really used or needed any of that.