ODBC and getopenfilename

[fritschen]

I'm working on a large fortran windows program with DVF 6.6a. I'm doing a simple call via ODBC to a microsoft acces 97 database. Normally without any problems, exept when I first - befor the connecting to the database - call he common dialog getopenfilename.
Again: when I call the api-function "SQLDriverConnect" befor I make a call to "GetOpenFilename" everything works fine but not vice versa (the program hangs). Even when I place the call to GetOpenFilename as the first statement in WinMain and immediately after that the call to "SQLDriverConnect" the program hangs (not when I do this vice versa). Probably the problem has something to do with the extra thread started - and terminated - by getopenfilename but I don't know this for sure.
I tried to break this down to small windows application but did not observe the problem there.

Has anyone an idea how to debug this or what could be going wrong?

[Steven_L_Intel1]

Did you set ofn%hwndOwner and ofn%hInstance correctly? Not doing so can cause all sorts of problems, including hangs. I find that GetForegroundWindow() is a good value to use for Owner.

Steve

[fritschen]

Yes I did. I even could reproduce the problem when I used your demo routine to call getopenfilename. I just have to open the box and press cancel. When I try to connet after that the program hangs. I observed that the SQLDriverConnect routine hangs after loading some dll's (saw this in the debugger) and loaded these dll's by hand (with LoadLibrary) but the problem persited. The call to SQLDriverConnect seems also to be correct. I reproduced the problem also by invoking a c++-demo source by fortran.

[canaimasoft]

Just a suggestion, although this might not be the problem at all. Try declaring the handles passed to SQLDriverConnect as volatile variables.

Another detail if you are using the SQL_DRIVER_PROMPT, SQL_DRIVER_COMPLETE or SQL_DRIVER_COMPLETE_REQUIRED: Microsoft changed the behavior of SQLDriverConnect since ODBC 2.5; a valid window handle is required whenever ODBC prompts for connection information (before a null handle could be passed without problems).

regards,

Marco A. Garcia
Canaima Software, Inc.
www.canaimasoft.com

[fritschen]

In my interface to SQLDriverConnect only InString,OutString and lOutString (like in the api-ref) are declared as !DEC$ ATTRIBUTES REFERENCE. I'm also passing a valid hwnd. I could however reproduce another strange behaviour after calling getopenfilename (probably having the same source of error): on win2000 and xp systems calling an additional thread after having called getopenfilename fails. The return code of getlasterror() is 8 (ERROR_NOT_ENOUGH_MEMORY). Apart from this the program works without any problems after the call to getopenfilename.

Ralf Fritschen

[fritschen]

Finally I found the problem: some months ago I had to load a large file. The program complained about its stack size. So I increased the reserved stack in the linker settings. Everything seemed to work fine after that.
By the way: do I have to load a large amount of bytes by seperate READ statements?

After removing the extra reserved bytes in the stack allocation linker tab, connecting to the data base and creating a new thread succeded.

Ralf