[AccessD] was SQL Server queries - appending strings

John W. Colby jwcolby at colbyconsulting.com
Sun Feb 1 11:37:54 CST 2004


In fact there are valid reasons for going to SQL Server, without expecting a
massive speedup.  Things like:

BE expansions, compactions not happening because users still in the db, lock
files that don't clear even when every one is out of the db, lock files that
can't be cleared at ALL without resetting the server, compacts fail as a
result.

Backups not happening because of open MDB files (SEE ABOVE).

Memo fields causing locks on adjacent records preventing users from saving
their memo records.

MDB Database corruptions due to the well known problems with memo fields,
causing maintenance for someone to clean up these corrupted memo fields.

The ever present possibility of MDB corruptions due to NIC problems, power
outages at workstations as they write to the MDB etc.

Limits on the numbers of indexes available in Access due to referential
integrity using indexes for foreign keys, reducing the remaining indexes
available for dates, strings etc.

And finally, there will be parts of the app that can be sped up (I think)
even using ODBC, things like a "claim find" search screen that doesn't need
updateable recordsets, where the entire thing may be able to be pushed out
to the server.

This client is climbing past 50 concurrent users where when I started they
had about 25.  They are doing the obvious, buying a new dual proc server to
run this thing, putting the data store into SQL Server (assuming I say
'go'), splitting their LAN into segments, with gigabit links to the routers,
etc.

This client has a massive amount of data that they want available
"instantly", thus the tabbed metaphor.  They kept asking for more and more
things, some of which required some time consuming things like "TOP 1" from
child tables, available at a glance.  I explained that each of these slowed
the app down, but they wanted them.  Over time, a dozen of these kinds of
things, each slowing the whole down only a bit, the whole lot slowed the app
down a lot.  They wanted it, they asked for it, they were informed that it
would cause slowdowns, they insisted, they got it.

The biggest issue I have at the moment is that (in A2K which is what they
have) recordsets cannot be set as the recordsource without making the result
uneditable.  If I could do that, I'd be in much better shape than I am.
There appears to be no real alternatives (in A2K) to use much of the
capabilities of SQL Server to offload processing to the server, yet still
end up with editable recordsets / forms.

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Gustav Brock
Sent: Sunday, February 01, 2004 12:07 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] was SQL Server queries - appending strings


Hi Jim

> There is a lot of work in creating the 'data-interface' to MSSQL and
ADO-OLE
> is the only option (ODBC is too slow....) Stored Procedures are programs,
> subroutines and functions more than just queries. No 'query' import tools
> can work because though SQL SP work similar they are really quite
different
> in concept.

Too slow compared to what? Of course, ADP is the way to go for
Access/SQL Server, but - assuming a high quality LAN - speed of ODBC
compared to Jet and to the client's current needs may be fully
acceptable.

If John couldn't speak for himself, he would only need to quote the
messages on this thread to justify for the client that a total rebuild
of the app is too expensive - either it would kill the client's budget
or it would consume an unreasonable part of John's valuable time.

Now, we don't know why the client has obtained this SQL Server. Is it
an idea originated at the client without consulting John about the
consequences, or did John talk the client into it? In the first case
we have a classic example of a situation where the client may be a
fool but no one wins by stressing that point. Hooking the client's
data up via ODBC may quickly set his SQL Server into action with
little effort and within his budget, and he will be happy about his
decision; then later John can prepare a demo showing the advantages of
moving the app to an ADP but, if agreed to do so, at the costs of the
client.

This could very well be an example where (continued) business is more
important then technical excellence.

/gustav

_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com





More information about the AccessD mailing list