Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.
Problem is, the app runs fine for several hours and then crashes for some reason I cannot understand because it does not open an Winbatch Error Dialog nor does it crash so that a windows fatal exception window would occur. It simply terminates quietly with exit code -1073741571. This I know because meanhile I wrote a wrapper program which starts the compiled Server App and logs the return code. Also the amount of hours it runs is not a constant value. For example the first time it ran over 9 hours and terminated, the second time it ran about 8 hours and then exited.
Does anyone have a solution to this problem or an explanation what this exit code means? I would be really grateful, cause this app should run permanently and not terminate itself after some hours.
Thanx for any help. I'm really very clueless on this issue because I don't know there to start looking for the problem.
DebugTrace(@ON,"C:\bigdebug.txt")at the top of the program AND as the first line of every #definefunction and #defineSubroutine.
If you get worried about file size, you can add something like
debugcounter=0 ;to the top of the script then ;and then this is some main loop debugcounter=debugCounter+1 if debugcounter >= 1000 FileDelete("C:\bigdebug.txt") debugcounter=0 endifAFTER the crash occurs you can examine the debug trace log...and the next line that would have been added to the log is probably the line it crashed on.
Once we know what that line is...then we can start theorizing about the error.
retcode = qConnect(hdbc, Datasource, "", "")which establishes a connection to the database before making a query. Well, may there be a Memory Leak or something in the hdbc extender when one makes hundreds of connects and disconnects during some hours?
Here's the complete subroutine which is called before every query. Of course there's also a disconnect subroutine, which I can post as well if you like:
DefineSubroutine ODBC_Connect(datasource) DebugTrace(@on,gvRead("logfile")) henv = qAllocEnv() If henv == -1 retcode = qLastCode() xMessageAndMail("Fehler %retcode%","could not allocate SQL Environment Variable", GetIcon("@mbstop")) CleanUp() Endif hdbc = qAllocConnect(henv) If hdbc == -1 retcode = qLastCode() xMessageAndMail("Fehler %retcode%","could not allocate SQL Connection Handle", GetIcon("@mbstop")) CleanUp() Endif qSetConnOpt(hdbc, 103, 5, 0) ; SQL_LOGIN_TIMEOUT qSetConnOpt(hdbc, 101, 1, 0) ; SQL_READ_ONLY tries = 3 cnt = 0 while @True retcode = qConnect(hdbc, Datasource, "", "") If (cnt > tries) Then Break If (retcode == @qSuccess) || (retcode == @qSuccessInfo) Break EndIf cnt=cnt+1 TimeDelay(1) EndWhile If (retcode != @qSuccess) && (retcode != @qSuccessInfo) err=ODBC_Error_Ext(hdbc,1) xMessageAndMail(StrCat("Fehler",err),"Could not connect to Datasource%@CRLF%Please check that a User DSN with Name '%datasource%' exists", GetIcon("@mbstop")) CleanUp() Endif hstmt = qAllocStmt(hdbc) If hstmt == -1 retcode = qLastCode() xMessageAndMail("Fehler %retcode%","could not allocate SQL Statement Handle", GetIcon("@mbstop")) CleanUp() Endif return hstmt ; Statement Handle #EndSubroutine
I always keep my extenders up to date with vcheck.
The failing qConnect SQL return code is "[S1000 Simba Driver][Simba File System Base]", which is according to the creator nothing to worry about, you just have to reconnect. And It really happens very, very, rarely. Maybe 1 of 100 connects or so.
But I don't think it has something to do with the connect retries because meanwhile my app crashed 3 times, always at the mentioned connect statement and it was always the first try which killed the app (cnt=0). I will now create a separate log with an odbc connect counter and get back to you when I have the first results.
As I already have the latest Simba Driver and the eventlog also shows nothing unusual and because restarting the app gives you another 177 attempts I really think the problem must lie in the odbc_extender. Remember: I connect/disconnect to the driver for every query which is executed because else it may happen that the odbc_connection times out until the next request, so the driver does not know if the app already connected 100, 1000, 10000 times, cause every time the connection is recreated. I think if the problem would lie in the simba driver I would have to reboot the machine and restarting the app would not help.
So I went looking for another driver using google for a newer/fixed driver and I found a newer release (from another vendor, not the one I got my driver). Now with this release I can do 356 connects and with this driver the app doesn't exit silently, it crashes winbatch.exe (or if compiled the compiled exe) and when you look at the details you see that the 4D Open odbc driver dll caused the crash.
Problem Is I'm forced to use this driver because there is no alternative and I don't think you can fix it somehow within the odbc extender. But my question is: Is there a way to unload/reload the odbc dll or such a thing or maybe relaunch the program itself after 300 connects or something like that? Any ideas would be helpful... Thanx for your assistance.
Article ID: W16838
File Created: 2017:07:28:13:58:33
Last Updated: 2007:07:03:14:26:29