[AccessD] was SQL Server queries - appending strings

Charlotte Foust cfoust at infostatsystems.com
Wed Feb 4 10:38:45 CST 2004


In both A2k and XP, when a *form* with controls bound to an ADO
recordset in an MDB is read only regardless of recordset type.  It isn't
exactly the recordset that is read-only, it's the form interface to it
that is restricted.   That didn't change in AXP, but  I believe you can
bind a recordset to the form and use unbound controls, using code to
read and write the controls and update the recordset. I can't recall
whether I've tried that or not.  Generally, bound forms (with bound
controls) means DAO recordsets, even in AXP.

Charlotte Foust

-----Original Message-----
From: John W. Colby [mailto:jwcolby at colbyconsulting.com] 
Sent: Wednesday, February 04, 2004 4:00 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] was SQL Server queries - appending strings


I was under the impression that, using A2K, regardless of anything else,
binding a recordsource to a form made it read only.  AND that this
changes with AXP.

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Jim Lawrence
(AccessD)
Sent: Wednesday, February 04, 2004 2:16 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] was SQL Server queries - appending strings


Hi John:

I have a sample of code that was used in demonstrating a method at
populating a report and it is at the DBA site:
http://www.databaseadvisors.com/newletters/newsletter112003/0311UnboundR
epor
ts.htm (watch for wrap). All the code is not shown but it is all in the
ZIP file is a full source set. It only demos the connection between two
MDBs but it should give enough of an idea.

By simply changing the recordset type from 'adOpenStatic,
adLockReadOnly' to 'adOpenDynamic, adLockOptimistic' it should handle
'similar to' a bound recordsource. (MSQSQL locks only the rows retrieved
not by pages and then does all/most of the internal record management.)

Jim

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Colby, John
Sent: Monday, February 02, 2004 8:17 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [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
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

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



_______________________________________________
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