Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Move from Jet to ADP? 2

Status
Not open for further replies.

Darrylles

Programmer
Feb 7, 2002
1,758
GB
Hi all,

I am researching this topic as best I can via Google etc. Microsoft of course doesn't give information away cheaply (10 pages per useful nugget of info.).

I'm wondering if anyone here has experience of ADP and SQL Server Express in order that I can decide on whether or not I invest lot's of time in experimenting or perhaps discard the idea all together.

Current set-up:

Windows XP clients
MS Access 2003 - JET.
Split application (back-end data / front-end forms etc) - both on server.
Back-end size: 200 mb, front-end 30 mb.
Tables: 100. Queries. 200. Reports: 50.
50 users and growing. 20 max concurrent.

I understand that ideally: the front-ends should be on the clients, but after experimentation - it seemed to make v. little difference.
I also understand that 20 users is already 300% over-subscribed (performance-wise).

The application resides on a common data-file server (I know - I know, but you'll know how companies work also). Network speeds are atrocious and rapidly declining. I am going through a long drawn-out process of negotiating re-location to a 'dedicated' virtual server.
I use the 'split' method to make copying the front-end to other locations much more efficient for development purposes.

Before the move to a virtual server happens, I may as well experiment with a sub-set of the application by using Access 2003 as the front-end and SQL Server Express on the back-end. I realise that there is also a 5 user restriction (and then it get's slow - intentionally), but, I will still be able to compare data-retrieval speeds etc. Once proved, then budget won't be a problem for full SQL Server licenses.

The application also connects to different Oracle databases (which cannot be used for development purposes).
The database design is relational and normalised, app. is VB only (as opposed to macros), generally professionally developed.
The possibility of moving to a later MS Access version is possible (although will be traumatic - as you can't create an Excel spreadsheet without first checking with Governance).

Questions:

1) Has anyone got any experience of this intended set-up, and any negatives or positives to relate?
2) Is the transition (conversion to stored-procs etc) messy, many inconsistencies?
3) I'm not clear on the front-end data connections: linked / strings / pass-thru' queries or what?
4) Will a move to SQL Server Express show any immediately obvious performance gains (all other things being equal)? (I'm assuming that a 'true' client-server database will help).

Any pointers will be very much appreciated - thanks in advance.

ATB

Darrylle

Never argue with an idiot, he'll bring you down to his level - then beat you with experience.
 
Darrylle, you can have a look at this thread I started.

thread181-1527336


Hope it helps.

Paul
 
From my experience I would say stay away from ADP's. I found it interesting that Paul's thread having people say that MS suggests linked tables.

What ADP's give you is native support in Access for SQL objects. That is only true if you keep your Access version up with SQL Server... Access 2003 can't manage a SQL 2005 database. What you lose is MDB tables. You can't link in access (link to odbc data sources, text files etc). Just get a real SQL Server and use the native SQL tools.

With an MDB you CAN link to your SQL tables but this CAN be slower than using JET (Access's native database engine) because a JET query may do a table scan of a SQL database... Enter the SQL Pass Through Query (SPTQ). Basically the MDB way of running a query directly on the server. This WILL be faster than Jet, handle concurrent users and large datasets better. The lazy thing would be to link your tables and still use them behind forms. The better way is to make your form's unbound and populate and modify them with SPTQ.

All and ADP does is force you to use NATIVE SQL server objects for queries and tables. This is very similar to using an MDB properly written with SPTQ.

Should you learn SQL server and store your data there? YES.
Should you use an ADP? NO. You simply lose some good features, your transition is all or nothing and some things are just weird (search this forum for posts from me).

If you upsize your MDB to SQL server, you can work on the really slow parts first. Inerestingly, you may go ahead and make an ADP so it upsizes as many queries for you as possible and promptly throw the ADP file away. Then in a new database file link the tables in a new MDB, make SPTQ for all the queries and import anything missing from the original MDB (the upsize wizard is not smart enough to translate everything even if it has a SQL equivalent).

Remember, MDB's support ADO just as well as ADP's. The only reason I can think of to maybe use an ADP is if you are NOT going to use windows authentication. Dealing with log in's everytime you want to run a query or saving passwords in your Access linked tables or SPTQ's is a bad idea.

So my advice:

Use SQL Server for your Backend
Use Windows permissions for security in SQL Server
Use and MDB (or maybe publish and MDE).
 
Wow... I just reread that... sorry for all the and's instead of an's. At least I was consistent :)
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top