Upgrading backend from Access 97 to sql server

Kevin;

Maybe if you had the balls to be a decent SQL Server developer / DBA_-
then maybe you could have helped him out.

Anyone using Access MDB / ACCDB against SQL Server -- is too stupid to
be employed

ADP is vastly superior-- in every regard.

#1 - name the steps to build a form-- based on a sproc-- in MDB
#2 - it takes _ZERO_ config for ADP.

Maybe if you had a backbone-- and could carry 3,000 applications--
then maybe they'd be more successful.
But your premise is that 'Access is neat' is done and over.

Anyone using Access as a database should be fired and then spit upon.

-Aaron










On Jun 28, 6:57 am, "TheSQLGuru" wrote:
> I have a client that about 3 years ago 'upgraded' about 3000 access
> databases to sql server.  Performance was a complete DOG.  Partly because
> they didn't know anything about how to optimize/configure the server itself.
> But a large part of the problem was the massive amount of looping,
> row-by-row ADO code that did the processing.  To get anything like 'good'
> performance you will need to upgrade your code to include more set-based
> logic.
>
> Having said that, I do think that an appropriately configured sql server
> will be a faster platform for your data even with your existing code.  From
> there you can do incremental, targeted code improvements where you find the
> choke points.
>
> Oh, the client I mentioned didn't have or hire a DBA and they paid a serious
> price for it.  They lost clients because of their performance issues.  I
> strongly urge you to at least hire someone interim to help get you up and
> going on SQL.  Long term you really do need someone knowledgeable to take
> care of your server and databases.  Note that there are now several
> outsourcing companies that can do this management for you.
>
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
>
> "John" wrote in message
>
>
>
>
>
> > Hi
>
> > I have a typical access app with both front and back ends in access 97.
> > The database is running slow due to number of users approaching 20. I
> > would ideally like to upgrade the backend to sql server if that would
> > improve performance. My questions are;
>
> > a) Would this help in performance significantly i.e. is it worth the time?
>
> > b) What route should I choose? Should I upgrade the app to a later version
> > of access first and/or switch to adp instead of mdb?
>
> > Any pointers to help upgrade access to sql server would be appreciated.
>
> > Thanks
>
> > Regards- Hide quoted text -
>
> - Show quoted text -
 >> Stay informed about: Upgrading backend from Access 97 to sql server 

Gotta disagree with your statements and especially your misogyny. If you
can't be civil, please stay off the public forums.

There are a huge array of commercial applications that have been (and still
are) build on Access databases.

--
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net


"a a r o n . k e m p f @ g m a i l . c o m" wrote in
message

suboptimal access applications.. need to be moved to SQL Server-- so
that you can run a wizard and build some indexes.

and optimize queries.
and optimize schemas.

working on a database-- where it's impossible to change anything--
while anyone else is using it-- and then bitching about sub-optimal
schemas-- is like shooting yourself in the foot.

USE A DATABASE THAT SUPPORTS MULTIPLE USERS.

Only a retard or a WOMAN-- would be stupid enough to use MS Access for
a database.

-Aaron



On Jun 29, 9:16 am, "Rick Brandt" wrote:
> TheSQLGuru wrote:
> > You are welcome to disagree. But please reread my post carefully. I
> > never said it wasn't EASY to migrate. I said primarily that it will
> > take some work (probably significant) to get an optimally performing
> > application. Most Access applications I have encountered (and in fact
> > built in a previous life) were primarily procedure-based (i.e.
> > row-by-row) processing, not set-based processing. That is where real
> > performance comes in. Schema's created by many Access application
> > designers are often suboptimal as well - again in my experience.
>
> I don't think it is very productive to talk about the efficacy of
> migrating
> sub-optimal Access/Jet designs to Access/SQL Server. Sub-optimal is
> sub-optimal and the back end used makes little difference. The row-by-row
> processing you describe is mostly produced by "programmers" with little
> database work in their background. I do not see that much in Access users
> (even novices) that do not come from a programming environment.
>
> The truth of the matter is that when looking at a *proper* Access/Jet
> application that has evolved to a point where a server engine's advantages
> reach a tipping point to make such a move a requirement, it really is not
> a
> difficult nor expensive transition to make.
>
> Aaron has a unique talent in making a sound argument sound like utter
> bullshit, but if you look past the messenger (or consult with other
> messengers), and examine just the premise, SQL Server's free or
> close-to-free variants really are viable options for just about anyone
> that
> has those requirements.
>
> Moving to an ADP is a separate question altogether and would likely
> require
> a more significant amount of work to transition to. I cannot speak with
> much experience about ADPs as I have always had requirements that make a
> *SQL Server only* solution completely out of the question.
>
> In situations where SQL Server exclusivity is not a problem then perhaps
> ADPs are perfectly suited to the task. I would however need to see them
> far
> surpass the abilities of MDB/ODBC simply because that exclusivity might
> not
> last forever and then I am stuck with an application that cannot deal with
> a
> requirement to change engines. Taking that risk means that ADPs cannot
> simply be "as good as" MDB/ODBC, but must be so much better as to make
> that
> risk tenable. I have not seen much evidence to suggest that.
>
> --
> Rick Brandt, Microsoft Access MVP
> Email (as appropriate) to...
> RBrandt at Hunter dot com
 >> Stay informed about: Upgrading backend from Access 97 to sql server 

civility?

are you kidding me?

this is about 100 times bigger than civility. This is more like a
civil war.

'well behaved women never got anywhere'. or whatever that stupid
saying is.

-Aaron


On Jul 2, 8:09 am, "TheSQLGuru" wrote:
> Gotta disagree with your statements and especially your misogyny.  If you
> can't be civil, please stay off the public forums.
>
> There are a huge array of commercial applications that have been (and still
> are) build on Access databases.
>
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
>
> "a a r o n . k e m p f @ g m a i l . c o m" wrote in
> messagenews:b14eb920-03cb-4a4c-b468-93c39afedde0@s21g2000prm.googlegroups..com...
> suboptimal access applications.. need to be moved to SQL Server-- so
> that you can run a wizard and build some indexes.
>
> and optimize queries.
> and optimize schemas.
>
> working on a database-- where it's impossible to change anything--
> while anyone else is using it-- and then bitching about sub-optimal
> schemas-- is like shooting yourself in the foot.
>
> USE A DATABASE THAT SUPPORTS MULTIPLE USERS.
>
> Only a retard or a WOMAN-- would be stupid enough to use MS Access for
> a database.
>
> -Aaron
>
> On Jun 29, 9:16 am, "Rick Brandt" wrote:
>
> > TheSQLGuru wrote:
> > > You are welcome to disagree. But please reread my post carefully. I
> > > never said it wasn't EASY to migrate. I said primarily that it will
> > > take some work (probably significant) to get an optimally performing
> > > application. Most Access applications I have encountered (and in fact
> > > built in a previous life) were primarily procedure-based (i.e.
> > > row-by-row) processing, not set-based processing. That is where real
> > > performance comes in. Schema's created by many Access application
> > > designers are often suboptimal as well - again in my experience.
>
> > I don't think it is very productive to talk about the efficacy of
> > migrating
> > sub-optimal Access/Jet designs to Access/SQL Server. Sub-optimal is
> > sub-optimal and the back end used makes little difference. The row-by-row
> > processing you describe is mostly produced by "programmers" with little
> > database work in their background. I do not see that much in Access users
> > (even novices) that do not come from a programming environment.
>
> > The truth of the matter is that when looking at a *proper* Access/Jet
> > application that has evolved to a point where a server engine's advantages
> > reach a tipping point to make such a move a requirement, it really is not
> > a
> > difficult nor expensive transition to make.
>
> > Aaron has a unique talent in making a sound argument sound like utter
> > bullshit, but if you look past the messenger (or consult with other
> > messengers), and examine just the premise, SQL Server's free or
> > close-to-free variants really are viable options for just about anyone
> > that
> > has those requirements.
>
> > Moving to an ADP is a separate question altogether and would likely
> > require
> > a more significant amount of work to transition to. I cannot speak with
> > much experience about ADPs as I have always had requirements that make a
> > *SQL Server only* solution completely out of the question.
>
> > In situations where SQL Server exclusivity is not a problem then perhaps
> > ADPs are perfectly suited to the task. I would however need to see them
> > far
> > surpass the abilities of MDB/ODBC simply because that exclusivity might
> > not
> > last forever and then I am stuck with an application that cannot deal with
> > a
> > requirement to change engines. Taking that risk means that ADPs cannot
> > simply be "as good as" MDB/ODBC, but must be so much better as to make
> > that
> > risk tenable. I have not seen much evidence to suggest that.
>
> > --
> > Rick Brandt, Microsoft Access MVP
> > Email (as appropriate) to...
> > RBrandt at Hunter dot com
 >> Stay informed about: Upgrading backend from Access 97 to sql server 

commercial apps?

ROFL

you mean little shareware stuff? how cute.

-Aaron

http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine
JET stands for Joint Engine Technology, sometimes being referred to as
Microsoft JET Engine or simply Jet. Microsoft Access and Visual Basic
use or have used Jet as their underlying database engine. It has since
been superseded, however, first by Microsoft Desktop Engine (MSDE),
then later by SQL Server 2005 Express Edition and most recently by SQL
Server 2005 Compact Edition, and no longer exists as a component of
Microsoft Data Access Components (MDAC). For larger database needs,
Jet databases can be upgraded (or in Microsoft parlance, "up-sized")
to Microsoft's flagship database product, SQL Server 2005.




On Jul 2, 8:09 am, "TheSQLGuru" wrote:
> Gotta disagree with your statements and especially your misogyny.  If you
> can't be civil, please stay off the public forums.
>
> There are a huge array of commercial applications that have been (and still
> are) build on Access databases.
>
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
>
> "a a r o n . k e m p f @ g m a i l . c o m" wrote in
> messagenews:b14eb920-03cb-4a4c-b468-93c39afedde0@s21g2000prm.googlegroups..com...
> suboptimal access applications.. need to be moved to SQL Server-- so
> that you can run a wizard and build some indexes.
>
> and optimize queries.
> and optimize schemas.
>
> working on a database-- where it's impossible to change anything--
> while anyone else is using it-- and then bitching about sub-optimal
> schemas-- is like shooting yourself in the foot.
>
> USE A DATABASE THAT SUPPORTS MULTIPLE USERS.
>
> Only a retard or a WOMAN-- would be stupid enough to use MS Access for
> a database.
>
> -Aaron
>
> On Jun 29, 9:16 am, "Rick Brandt" wrote:
>
> > TheSQLGuru wrote:
> > > You are welcome to disagree. But please reread my post carefully. I
> > > never said it wasn't EASY to migrate. I said primarily that it will
> > > take some work (probably significant) to get an optimally performing
> > > application. Most Access applications I have encountered (and in fact
> > > built in a previous life) were primarily procedure-based (i.e.
> > > row-by-row) processing, not set-based processing. That is where real
> > > performance comes in. Schema's created by many Access application
> > > designers are often suboptimal as well - again in my experience.
>
> > I don't think it is very productive to talk about the efficacy of
> > migrating
> > sub-optimal Access/Jet designs to Access/SQL Server. Sub-optimal is
> > sub-optimal and the back end used makes little difference. The row-by-row
> > processing you describe is mostly produced by "programmers" with little
> > database work in their background. I do not see that much in Access users
> > (even novices) that do not come from a programming environment.
>
> > The truth of the matter is that when looking at a *proper* Access/Jet
> > application that has evolved to a point where a server engine's advantages
> > reach a tipping point to make such a move a requirement, it really is not
> > a
> > difficult nor expensive transition to make.
>
> > Aaron has a unique talent in making a sound argument sound like utter
> > bullshit, but if you look past the messenger (or consult with other
> > messengers), and examine just the premise, SQL Server's free or
> > close-to-free variants really are viable options for just about anyone
> > that
> > has those requirements.
>
> > Moving to an ADP is a separate question altogether and would likely
> > require
> > a more significant amount of work to transition to. I cannot speak with
> > much experience about ADPs as I have always had requirements that make a
> > *SQL Server only* solution completely out of the question.
>
> > In situations where SQL Server exclusivity is not a problem then perhaps
> > ADPs are perfectly suited to the task. I would however need to see them
> > far
> > surpass the abilities of MDB/ODBC simply because that exclusivity might
> > not
> > last forever and then I am stuck with an application that cannot deal with
> > a
> > requirement to change engines. Taking that risk means that ADPs cannot
> > simply be "as good as" MDB/ODBC, but must be so much better as to make
> > that
> > risk tenable. I have not seen much evidence to suggest that.
>
> > --
> > Rick Brandt, Microsoft Access MVP
> > Email (as appropriate) to...
> > RBrandt at Hunter dot com
 >> Stay informed about: Upgrading backend from Access 97 to sql server 

"So Sorry For Poor Aaron"
wrote in message
> Aaron head done been depecrated. Aint stuffed wid no brain no mo. All 'em
> Big brothers do miss he, dey say, "U com back soon, baby."
>
> "a a r o n . k e m p f @ g m a i l . c o" wrote:
>
>> ADP, yes, yes, yes!
>>
>
 >> Stay informed about: Upgrading backend from Access 97 to sql server 

hola como estas

"marinorona" wrote in message

>
> "So Sorry For Poor Aaron"
> wrote in message
>
>> Aaron head done been depecrated. Aint stuffed wid no brain no mo. All
>> 'em
>> Big brothers do miss he, dey say, "U com back soon, baby."
>>
>> "a a r o n . k e m p f @ g m a i l . c o" wrote:
>>
>>> ADP, yes, yes, yes!
>>>
>>
>
 >> Stay informed about: Upgrading backend from Access 97 to sql server