Fog Creek Software
Discussion Board

MS Access and VS.NET

Does anyone know if there's a good way to use VS.NET 2003 to manage an Access database?  I just tried to build a database project so that I could generate creation scripts and eventually change scripts for an Access db that's part of an app I'm writing.

No go.

The "Generate Create Script" menu choice is missing from all the Access tables.

I tried Google, but of course, MS likes to name its products after common words (.net, access, word, etc.) so I had no luck.

If VS.Net can't do it, does someone know of some other utility?  I know I can create these things by hand, but I'd have more faith in an automated tool, as I'd likely forget small changes.

David (
Tuesday, June 15, 2004

I thought the standard way to do "creation" scripts in Access was to simply copy a blank db file that you hide somewhere in your install directory?

Tuesday, June 15, 2004

If you're trying to design tables in Access and then generate create scripts from those, like you can in SQL Server, then no, I don't think Access does that.

But if you create the scripts on your own, Access will accept the DDL commands.

You could also use ADO.NET, or even DAO or ADO, to generate the tables.

Wednesday, June 16, 2004

You can create a blank MDB file in VBS, which I assume would be relatively easy to convert to ASP, or maybe even .NET if you know the comperable objects:

Wednesday, June 16, 2004

MS is trying to kill Access because it's a support nightmare and has been used to build all sorts of applications *FAR* beyond its original scope.  While I happen to think this is rather impressive, they don't like it.

If you look at most of the .Net stuff, they talk about using various scaled-down versions of SQL Server to do most of the database interactions.  This applies to .Net on the desktop and the Compact Framework (for handhelds).

There are libraries out there that provide Access functionality, but the only one that I found had any value claimed to be "Open Source" but required you to pay $100+ for the dll and a few $k for the source.  It sounds like hijacking of the term to me...

Wednesday, June 16, 2004

"MS is trying to kill Access"

That's news to me...

"[...] has been used to build all sorts of applications *FAR* beyond its original scope."

Yes, we're always unhappy when too many people use our products. [grin]

Admittedly, the biggest problem with Access is when people try to grow a grassroots mdb for department-level or [ack!] enterprise-level use. But that's why we provide upsizing wizards, transition plans and strategies, and the ability to use MSDE as a back end for Access (which provides a direct migration path to SQL Server when necessary).

For the OP - check out using MSDE as a back end for your project; then I believe you'll have the create scripts option you need.

***NOTE: MSDE is a throttled SQL Server. This means you MUST patch it against viruses and worms, and it will require patch management once installed. Granted that this is a trade-off on maintainability and scalabilty vs. cost. But it's an option you can evaluate.


Wednesday, June 16, 2004

Searching for things like .NET is hard. The first result for .NET is PHP!

You'll have better luck if you use the Microsoft Google search:

Wednesday, June 16, 2004

The suggestion of using a blank db in the installation is a good one.  It's actually what I've been using, but I never thought it was too elegant.

What I really wanted was a nice way to generate change scripts for when I need to modify the database.  I can write them myself and have the app apply them to the database, but it would be nice if that were automated.

Philo suggested MSDE.  I did look into that, but it just seems "big" for what I need.  Is it really a reasonable solution for a smallish consumer app?  It looks like you have to install it seperately from your app's installation.

Thanks for the posts.  I think people confirmed what I thought - I can't really do what I had hoped to.

David (
Wednesday, June 16, 2004

David - whoops, I missed that it was a consumer app.
In that case, I'd stick with Access and do the blank mdb thing.


Wednesday, June 16, 2004

Thanks, Philo.  That advice helps.  That's one less thing to worry about.

It looks like if I want better dev tools for managing dev of an Access database, I'll need to pay for them.  Since this is my side project, that means I'll do without!

David (
Wednesday, June 16, 2004

>>MS is trying to kill Access because it's a support nightmare and has been used to build all sorts of applications *FAR* beyond its original scope.  While I happen to think this is rather impressive, they don't like it.

I have been hearing that rumor for years and years. Heck, we got several new versions in the pipe…can’t say that for VB6 can we?

Who is out lasting who on this one? I betting on ms-access for the next 10 years.

How can you possibly make the above statement about MS trying to kill ms-access? (what they count 250 million users?....that thing is SOOOOOOO popular right now!

The JET database engine is BY FAR and away the most popular data engine.

The development team at MS right now is as LARGE as it has ever been for ms-access.

We all know that JET’s native data object is of course the OLD DAO (we are talking pre-ado days).

Well, guess what? The brand new version of access 2003 now includes a DEFAULT reference to the dao object (the last two versions of ms-access DID NOT!).

How you can say this product is on its way out! Do you have a quote, or a source?

With access 2003, we even now got themed controls

(here is some screen shots of themed controls vs non).



Right now, the ms-access team at MS is the LARGEST it has ever been (the teams were recently expanded). The product is not even close to being dropped, or on its way out.

You can read about my lord of the ms-access ring quest here:

Albert D. Kallal  (Microsoft Access MVP)
Edmonton, Alberta Canada

Albert D. Kallal
Thursday, June 17, 2004

*  Recent Topics

*  Fog Creek Home