Martin Reid
mwp.reid at qub.ac.uk
Wed Feb 4 11:55:44 CST 2004
http://support.microsoft.com/default.aspx?scid=kb;EN-US;281998 Have a read at that Martin ----- Original Message ----- From: "Charlotte Foust" <cfoust at infostatsystems.com> To: "Access Developers discussion and problem solving" <accessd at databaseadvisors.com> Sent: Wednesday, February 04, 2004 4:38 PM Subject: RE: [AccessD] was SQL Server queries - appending strings > 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 > _______________________________________________ > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com >