SQLSetProp failing for connection #0

[Olaf Doschke]

An application I maintin is making several default settings for SQL connections by SQLSETPROP() calls for handle=0, as follows:

=SQLSETPROP(0, "Asynchron", .F. )
=SQLSETPROP(0, "DispWarnings", .F. )
=SQLSETPROP(0, "BatchMode", .T. )
=SQLSETPROP(0, "Transactions", 1 )
=SQLSETPROP(0, "DispLogin", 1 )
=SQLSETPROP(0, "ConnectTimeOut", 15 )
=SQLSETPROP(0, "IdleTimeOut", 0 )
=SQLSETPROP(0, "QueryTimeOut", 0 )
=SQLSETPROP(0, "WaitTime", 100 )

This fails on the line about the Transactions setting with ERROR 1541 (the message is "Connection #0 is busy"). How could that be? There is no real connection, this is all just setting defaults.

It is done repeatedly, which I could change to once at init, but it always and only fails on the Transactions line.

OS is Windows Server 2012 R2 (Datacenter) 64bit, if it matters. And it's a used as a Terminal Server.

I will try to simply remove the line, as 1 (automatic) is the default setting for transactions anyway. But I'd like to know why that could cause error 1541 and make sure the error will also never happen for any other setting.

By the way, this is another of those errors not having occured earlier, although this code is used for several years now, previously in Vista/7/8 clients and on 2008 Servers. It happens reproducable now.

Bye, Olaf.

 

[Dan Freeman]

Windows update?

 

[Olaf Doschke]

Well, if so, then not the current patch day updates. That problem was reported since the current, new setup of this server. So it's an initial error of a new system.

Bye, Olaf.

 

[DSummZZZ]

Does the order of the setting make a difference?


-Dave Summers-

Even more Fox stuff at:

http://www.dave-summers.net/foxprolinks.htm

 

[Olaf Doschke]

Next time I'm able to try, I'll check that out, Dave.

 

[Olaf Doschke]

Interestingly there is a thread over at MSDN foxpro general forums with someone else on Win2012R2 having an error with the same SQLSetProp of handle 0 about the Transactions setting, too. Just another error "Must specify additional parameters", which is odd, of course. But this leads me to think the problem is in the OS, if not both of us have the wrong runtime paired with the EXE.

Bye, Olaf.

 

[vhad]

It happens to me too on Windows Server 2012 Standard R2 64bit.
My workaround is running the app (exe) with compatibility mode for Windows 7 or 8.