Comment: Access ADPs and SQLServer 2005
Access ADPs for SQLServer 2000 have been a God-send for a lot of us: integrated back-end development with what has to be the easiest/fastest database forms application out there with the added benefit of being able to implement real client-server data retrieval (serverfilters etc. etc.). It isn't just about maintaining developer skills, this is about speed and breadth of development. We have business users who are quite comfortable working in ADPS, running reports, adding data, building forms.
And if no Access ADPs, then what? Back to ODBC linked tables, poor support for stored procs, functions, data type incompatibilities etc. etc.? No, no, no...! This is not progress.
From what I understand, SQLExpress is going to be the next low-end RDBMS, essentially replacing Access DBs - that's good. What's bad is the lack of usable GUI for SQLExpress. The lack of viable GUI tools with SQLExpress is a big issue - and the XM is nowhere near a graphical tool (though I understand this is only a CTP). I can do backups/restores from ADPs but I'm back in the dark ages with XM, typing in commands that I had the joy of dumping from my memory 6 years ago.
If a MS Product Manager is listening: please go to bat for Access as a relatively tightly-coupled front-end to SQLServer 2005 - even if not entirely complete in its support for embedded CLR and all the new bells and whistles. One of the real beauties of the Access/SQLServer combination in the past has been the ability to put together fast, workable, reliable and extremely cost-effective front-end/back-end solutions for departments. The scary aspect of the SQLServer 2005 product path (while there are certainly lots of upsides) is that front-end development looks like its going to be a very expensive and unpleasant experience - even with SQLExpress. Unless there is a tool like Access for front-ends, I suspect that business user adoption of SQLServer 2005/Express will be slow - if we're anything to go by.
