I'm not sure I understand the problem. Are you saying that multiple calls to the SQLStringConnect function are returning the same handle? If so, is it possible you have some shared connection option set? I know there is a SHARED property for connections in VFP although I don't believe that is set on by default.
Other random thoughts... I would put the ASSERT before the initial SQLStringConnect although it's certainly easy enough to just set an earlier breakpoint in the debugger since you're already using ASSERTS to trigger a debugging session. What is the scope of the nConnectionHandle variable? Is it explicitly declared prior to the call to SQLStringConnect? If not, are you resetting it to 0 or -1 each time the SQLStringConnect is invoked? Have you tried a quick & dirty SQLEXEC with the nConnectionHandle value immediately after it is supposed populated with a positive integer value? If you don't have a proper handle, that should throw some kind of error that can be seen with AERROR(). -- rk -----Original Message----- From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Paul Newton Sent: Wednesday, June 01, 2016 4:16 AM To: profoxt...@leafe.com Subject: RE: SQLStringConnect Thanks Ted I highlighted the SQLStringConnect line in the watch window and dragged it to the command window - IOW am issuing _exactly_ the same command There is no typo in cConnectionString - and even if there were I would expect SQLStringConnect to return -1 I have put an AERROR(test) immediately after the SQLStringConnect call and that shows nothing I also put SQLSetProp(0, "DispWarnings", .T.) immediately before the SQLStringConnect call and it made no difference I am completely stumped ... Paul -----Original Message----- From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Ted Roche Sent: 31 May 2016 18:00 To: profoxt...@leafe.com Subject: Re: SQLStringConnect On Tue, May 31, 2016 at 11:33 AM, Paul Newton <paul.new...@pegasus.co.uk> wrote: > nConnectionHandle = SQLStringConnect(cConnectionString) > Assert .F. > > In the debugger Watch window nConnectionHandle shows with value 1 If I > check SQLGetProp(1,"ConnectString") it shows expression cannot be > evaluated > > If do another SQLStringConnect in the command window, nConnectionHandle still > shows as 1 but now SQLGetProp(1,"ConnectString") shows the connection string > I used. When you do the second SQLStringConnect, are you using the explicit cConnectionString, or are you typing out the connection string again? I'd check the value of cConnectionString in the debugger and see if there's a typo. Check your error handler to ensure you're not suppressing the error by mistake. There's also a global setting for SQLStringConnect to raise or suppress errors, SQLSetProp(0, "DispWarnings", .T.) Note that Zero for the first parameter sets the setting globally. Reference: https://msdn.microsoft.com/en-us/library/dtytxez4(v=vs.80).aspx > > It _seems_ as if SQLStringConnect is returning 1 even though in fact a > connection has not been established Any ideas would be very much > appreciated as I have wasted a lot of time on this so far > > Many thanks > > Paul Newton > [excessive quoting removed by server] _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/bn4pr10mb0913f6d5450a4b6bb5671262d2...@bn4pr10mb0913.namprd10.prod.outlook.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
