October 23rd, 2002, 9:03 am
Okay, for what it's worth, here's my opinion.1) Access is great for rapid prototyping stuff on your local drive - although when you move to a proper industrial-strength DB such as Sybase or SQL server etc.. you're going to spend alot of time actually setting up your stored procs, views and triggers properly. If you don't do this, and directly "port" an Access project over to SQL server (say) by simply copying the table structure then you'll miss out on alot of the powerful stuff that comes with a proper DB. If you have a dev server running an instance of SQL server 2K, better to set things up from the out in that environment. You can also always rent some web based SQL space from the likes of brinkster etc... to do your dev/proof of concept work on provided you can get through your firewalls.2) Sybase is a bit of a no-no for me as it doesn't integrate very happily with any MS product. If you don't believe me, just try finding a good, stable ODBC type driver for Sybase on the web. There are some out there, but they're 3rd party written and prone to be slow (and, on a related point, don't like running stored procs on the server that reference the same table more than once in a given view... I had alot of fun finding that out, believe me.) Also, SQL server 2K ships with Enterprise Manager (very good front end if you're a little bit techie) whereas Sybase ships with ... SQL advantage, which is frankly (compared to Enterprise Manager) bollocks.3) I have used SQL 2K with C#.net - specifically on a asp.net project - and to be honest, once you get your head around the new ADO.net structure (namely it's now much less obvious as to how to return a recordset - you get a data set back which MS annoyingly expect you to bind to their rubbish DataGrid control) it's identical to working with SQL7 and VB6 (say). The .net architecture does ship with a specific SQL server connection driver, however, which is very fast.Conclusion?1) Use Access if your on a budget and your writing an app for personal, local use.2) Use a proper DB for anything that will require multiple clients running concurrently3) Use SQL server in preference to Sybase if you're target client is anything MS, the dev tools are better and Transact SQL has some cool additions that are missing in the standard SQL used by Sybase. And Sybase doesn't integrate with an MS environment very happily.4) I've never used Oracle, so this could be a viable alternative ('specially in a Java env)5) Database access works happily in .net once you get your head around the new ADO.net. After that, you should be doing all your data work on the DB in any case in the form of stored procs etc... so you're choice of dev environment should not make a difference.Dave