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