[AccessD] was SQL Server queries - appending strings

>In a number of cases I have used the conversion from ODBC to ADO-OLE to
resolve client bottle-necks issues.

What is this, and can I use it to get an editable bound form?

John W. Colby
The database guy


-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Monday, February 02, 2004 10:52 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] was SQL Server queries - appending strings


Hi Gustav:

I must reluctantly agree with your business assessment.

As for saying ODBC is slow, it works well with up to twenty or thirty
records but any larger amount... In a number of cases I have used the
conversion from ODBC to ADO-OLE to resolve client bottle-necks issues.

Jim

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Gustav Brock
Sent: Sunday, February 01, 2004 9:07 AM
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