Need Opinions - SQL Server
- Thread starter ACE
- Start date
Travis
Registered User.
- Local time
- Today, 10:07
- Joined
- Dec 17, 1999
- Messages
- 1,332
What is the User Base?
What is the Security Requirements?
How Large will it get?
There are many questions that you have to have the answer to in order to make a well informed stance on what would be the best to use.
What is the Security Requirements?
How Large will it get?
There are many questions that you have to have the answer to in order to make a well informed stance on what would be the best to use.
There will only be a few users (Under 10), security is not really an issure, and as for size... I would guess around 6 million records/season. Not very big, Access would be able to handle it!! The text file size would be (this is just a guess) under 100 mb's/year. This will grow as time goes on though.
Calvin
Registered User.
- Local time
- Today, 10:07
- Joined
- Jun 4, 2003
- Messages
- 286
Personal is if only you will be accessing it and it's located on your local workstation (test stations), since you have several people needing access go with Standard on it's own server. If your dealing with 10's of millions of records (either now or next year) you may want to go with Enterprise and a beefier server.
If using Access 2000 or newer as a frontend and SQL 2000 or newer for the database/backend look into creating an ADP (Access Project File) instead of an MDB (Access Database File). I think you'll be much happier with the performance.
If using Access 2000 or newer as a frontend and SQL 2000 or newer for the database/backend look into creating an ADP (Access Project File) instead of an MDB (Access Database File). I think you'll be much happier with the performance.
Last edited:
M
mission2java_78
Guest
If your upsizing your backend why are you keeping a cheap nasty looking front end in Access?
If you're going big...KING SIZE it..go with a vb front end to a SQL Server back end.
You'll thank me later.
No more stupid "Network errors", "Database corruption", all those great features of access...pffffffffffffffftttttt pathetic
If you're going big...KING SIZE it..go with a vb front end to a SQL Server back end.
You'll thank me later.
No more stupid "Network errors", "Database corruption", all those great features of access...pffffffffffffffftttttt pathetic
Travis
Registered User.
- Local time
- Today, 10:07
- Joined
- Dec 17, 1999
- Messages
- 1,332
Jon,
I agree that he would be happier if he used a VB front end, but he may have to consider development time.
I have found that I have a better time meeting the Clients goals if I first proto-type it in Access and then use VB and C++ to finialize. There is a lot less headaches doing it this way, especially when you have a client that starts sentences Oh and by the way I like this, but can we...
Also VB's built in Report engine leaves a lot to be desired (I usually go to a third party for these capabilities).
I agree that he would be happier if he used a VB front end, but he may have to consider development time.
I have found that I have a better time meeting the Clients goals if I first proto-type it in Access and then use VB and C++ to finialize. There is a lot less headaches doing it this way, especially when you have a client that starts sentences Oh and by the way I like this, but can we...
Also VB's built in Report engine leaves a lot to be desired (I usually go to a third party for these capabilities).
- Local time
- Today, 13:07
- Joined
- Feb 19, 2002
- Messages
- 47,343
Personally, I don't think that .adp's are ready for prime time. I'll stick with a good ol' .mdb fe. Do be sure to read the optomizing client/server articles on the Microsoft kb and make sure to use queries with where clauses as your form and report recordsources. I find performance to be fine with an .mdb front end provided I have optomized my data access.
It is an absoluted NO-NO to base a form on a table or an unlimited query if your be is other than Jet. You would essentially be opening a pipeline to the be db over which, Jet will just keep pulling data until the entire table has been transferred to the client. Not exactly optimum behaviour.
It is an absoluted NO-NO to base a form on a table or an unlimited query if your be is other than Jet. You would essentially be opening a pipeline to the be db over which, Jet will just keep pulling data until the entire table has been transferred to the client. Not exactly optimum behaviour.
