469,626 Members | 1,800 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,626 developers. It's quick & easy.

Upsizing To SQL Server

Can anyone point me to any info on the pros and cons of upsizing small
to medium size databases to SQL Server?

If the user base is never going to be more than about 10, the app
isn't totally mission critical and the record count will never get
into the hundreds of thousands, is upsizing even worth considering?

Any help is appreciated.

Jul 5 '07 #1
16 1673
If your DB size is never going to reach the 2GB limit then you would
be all right.

It's good practice to schedule a periodic shutdown (i.e. once a week)
of your access DB to perform compacting to keep the size within
reasonable limits.

My experience (I'm not an expert though) says that the main adavantage
of upsizing to SQL Server is that your data now can grow more than
2GB. But you lose functionalities as you still may have to have local
tables in access to do local querying, etc; upsizing means you have to
rewrite some of your code to keep the same functionalities you used to
have.

So, if your DB size will be less than 2GB and your user base is less
than 25 concurrent users I wouldn't upsize.

Perhaps some other folks with experience in this could share their
views.

HTH - Max

Jul 7 '07 #2
Thanks for the reply Max. For the systems that I have in production,
my concurrent user base probably won't even approach 10 and if the
backend mdb ever grows to 100mb I'll be really surprised. The main
reason for my question was that I've seen some bad press on using an
mdb as the backend. I don't know whether the people are purists or
not, but the advice was that a Jet backend isn't a real database and
SQL server should always be used as the backend or the developer
doesn't really know what they are doing.

This just didn't ring true because there are many very competent and
knowledgeable people who frequent this forum (some of them MVPs) who
use Jet backends extensively from what I can tell. Most of these guys
know infinitely more than I ever will, and for them to be using Jet I
figure in many cases where small database systems are involved, that
Jet is more than ample for the job.

Backend mdbs have worked really well for me over the years. I've had
almost no trouble with them and it is really easy to set a database up
via email and telephone without ever having gone to the site where the
database lives geographically. Many thanks to Tony Toews for his Auto
Frontend Updater that makes setting up individual client frontends a
breeze. I assume that with an SQL server backend it wouldn't be as
simple a zipping a few files and emailing them off.

I also assume that it isn't as simple as just dumping my current
backend tables onto SQL server. From what I've gleaned from trawling
this forum, the frontend application would have to be extensively
rewritten. I rely heavily on queries and I presume that this has a
bearing on things as well.
Jul 7 '07 #3
Hi Wayne - Totally agree with your comments. I'm not an expert either
but i have used MDB's as backends and never had any trouble; they are
also very easy to backup.

I think you are right; it seems to me that the aversion against MDB's
is a lot to do with purists spreading the fear. At the end of the day,
I think that for fast LAN deployments where you have < 25 concurrent
users nothing can beat Access; perhaps SQL Server has its strengths
but not in this space.

I also hear a lot of complaints about security and WAN speed of MDB's
and that these factors play an important role in deciding to upsize to
SQL server.

If there is anyone out there with experience in this subject I'd be
glad to learn about different views.

Jul 7 '07 #4
One plus is the chance for you to acquire a new skill set. Depending on
your situation this may or may not be attractive to you. If it were me,
I would take a small app that you know inside out, buy some good books
on sql server and sql server / access development and go for it.

Wayne wrote:
Can anyone point me to any info on the pros and cons of upsizing small
to medium size databases to SQL Server?

If the user base is never going to be more than about 10, the app
isn't totally mission critical and the record count will never get
into the hundreds of thousands, is upsizing even worth considering?

Any help is appreciated.
Jul 7 '07 #5
On Jul 5, 5:34 pm, Wayne <cqdigi...@volcanomail.comwrote:
Can anyone point me to any info on the pros and cons of upsizing small
to medium size databases to SQL Server?

If the user base is never going to be more than about 10, the app
isn't totally mission critical and the record count will never get
into the hundreds of thousands, is upsizing even worth considering?
You'll be able to say,
"Well, of course, MY applications all use MS-SQL as a backend."
This may help you score with nerd-pref chicks.
Otherwise, it's a total waste of time.

Jul 7 '07 #6
Wayne <cq*******@volcanomail.comwrote in
news:11**********************@i13g2000prf.googlegr oups.com:
I don't know whether the people are purists or
not, but the advice was that a Jet backend isn't a real database
These people are know-nothing idiots -- pay no attention to them.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jul 7 '07 #7
"lyle" <ly************@gmail.comwrote
You'll be able to say, "Well, of course, MY
applications all use MS-SQL as a backend."
This may help you score with nerd-pref chicks.
"Red-heads?" someone asked, with raised eyebrows.

Jul 8 '07 #8
Thanks all for the feedback. Lyle and David you have confirmed what I
suspected to be the case.
Jul 8 '07 #9
rkc
Wayne wrote:
Thanks all for the feedback. Lyle and David you have confirmed what I
suspected to be the case.
Really? That's all it took?
Jul 8 '07 #10
On Jul 8, 9:55 am, rkc <r...@rkcny.yabba.dabba.do.comwrote:
Wayne wrote:
Thanks all for the feedback. Lyle and David you have confirmed what I
suspected to be the case.

Really? That's all it took?
It dosen't show up in the posting but I copied my response onto a
stone tablet and sent it directly to Wayne by messenger service.
That's probably the reason it was treated as being so authorative. You
think I needed to do the burning bush thing too?

Jul 8 '07 #11
lyle <ly************@gmail.comwrote in
news:11**********************@o61g2000hsh.googlegr oups.com:
On Jul 8, 9:55 am, rkc <r...@rkcny.yabba.dabba.do.comwrote:
>Wayne wrote:
Thanks all for the feedback. Lyle and David you have confirmed
what I suspected to be the case.

Really? That's all it took?

It dosen't show up in the posting but I copied my response onto a
stone tablet and sent it directly to Wayne by messenger service.
That's probably the reason it was treated as being so authorative.
You think I needed to do the burning bush thing too?
When Lyle and David agree, it must be truth.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jul 9 '07 #12
On Jul 9, 10:48 am, "David W. Fenton" <XXXuse...@dfenton.com.invalid>
wrote:
The answer for both these questions is Windows Terminal Server.
Thanks David - Killed 2 birds with one stone :-)

Jul 9 '07 #13
Thanks Tony. No, the data is nowhere near as mission critical as the
example you give. There are only a handful of records being entered
each day and the data can be rekeyed if there is a problem. I have
around 30 databases in use, all with Jet backends and I have only had
one data corruption issue caused by a faulty network connection. This
is over a period of about 5 years. I don't know if I've just been
lucky or if this is about average. Most of the systems have only 5
users or so.

My original post was prompted by a discussion that I had on another
forum (not an Access forum) where somebody was adamant that Jet
backends were only for amateurs and they were nothing but trouble.
This just hasn't been my experience.

Jul 9 '07 #14
Wayne <cq*******@volcanomail.comwrote in news:1183671296.673111.180040
@x35g2000prf.googlegroups.com:
Can anyone point me to any info on the pros and cons of upsizing small
to medium size databases to SQL Server?

If the user base is never going to be more than about 10, the app
isn't totally mission critical and the record count will never get
into the hundreds of thousands, is upsizing even worth considering?

Any help is appreciated.
When we grant SQL permissions to users those permissions are independent
of Access (or any other application, for that matter).
If we create an ADP and connect using the same connection values we have
used in another Access application then all the objects for which we have
permissions will be open to us in that new ADP. But we will not be
constrained in our interaction with these objects by the other Access
application.
We may damage the data; we may have data available to us which we should
not.
I believe ODBC connections can be exploited in the same way, but I am not
familiar enough with ODBC to state that as a certainty.

A solution is to use MS-SQL Application Roles. When we use Application
Roles, a user has no permissions other than to log on. It is the
Application that has or seems to have permissions. Beyond the
application, (in a new ADP for example), the user cannot even see the
database objects, much less interact with them.

Access and Application Roles do not seem to mix well because Application
Roles give permissions to connections and Access may use many default
connections at the same time. Coding to grant those permissions to
connections used for Combo-Boxes, for example, may be a nightmare. (As an
aside I might point out that I am a very experienced VBA coder.) I
estimate using Applications Roles may increase development time by a
factor of three or more.

For these reasons I have stopped recommending the use of Access and MS-
SQL together, although I still enhance and maintain ADP applications for
which I have already wrestled with and defeated, more or less, the
problems of implementing Application Roles.

I have not studied this problem for more than a year; it's possible that
Microsoft has a new solution, or that an old solution existed about which
I am unaware.
But Microsoft's retreat from APDs causes me to guess that this is not
true.
As I pointed out I am not totally clear about how this relates to ODBC
connections; the little I know suggests the problem with be similar, but
I will emphasize the "little I know" here.

--
lyle fairfield

Ceterum censeo Redmond esse delendam
Jul 9 '07 #15
Wayne <cq*******@volcanomail.comwrote:
>Thanks Tony. No, the data is nowhere near as mission critical as the
example you give.
Glad to hear it.
>My original post was prompted by a discussion that I had on another
forum (not an Access forum) where somebody was adamant that Jet
backends were only for amateurs and they were nothing but trouble.
Tell him to come on over hear and make his sentiments know. <chuckle>
>This just hasn't been my experience.
Agreed.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Jul 9 '07 #16
Wayne <cq*******@volcanomail.comwrote in
news:11**********************@i38g2000prf.googlegr oups.com:
I have
around 30 databases in use, all with Jet backends and I have only
had one data corruption issue caused by a faulty network
connection. This is over a period of about 5 years. I don't know
if I've just been lucky or if this is about average.
I'd call that average, not lucky.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jul 9 '07 #17

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Gary Bouchard | last post: by
1 post views Thread by Big Time | last post: by
1 post views Thread by Calum Chisholm | last post: by
2 posts views Thread by Big Time | last post: by
12 posts views Thread by John | last post: by
3 posts views Thread by Devonish | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.