Multi-app projects using MSSQL freeze on the first attempt to access a data table. Single-app projects work as expected. Using Clarion 11.13505 ABC with multiple versions of MSSQL.
Is the connection string a threaded var or perhaps only defined at the app level and not linked to the data dll?
In all cases, the connection string is a global non-threaded variable defined in the dictionary.
This has been the case with my production app for more than 7 years but this problem has just surfaced a couple months ago.
Is it possible that someone has changed settings in the database by accident or without telling you forcing an exclusive opening? Not sure if this really helps but from what you describe it doesn’t look like something in the Clarion side.
In the case of my development machine, no one else has access. In the case of the production machine, it is possible but highly unlikely that someone changed the server.
The fact that a single exe works and multi-app projects don’t work, all using the same dictionary and connection string really confounds me.
Can you clarify that this multiple DLL project is the production app and it stopped working? Or is the working production app a different app?
Is the connection string exported from your data DLL and external to all of the other apps?
Both the production project and a small multi-dll test project using the same dictionary exhibit this problem. Also, an example FileManager3 multi-dll solution compiled by CapeSoft using a different Clarion version exhibits the problem.
The connection string is an unthreaded global defined in the dictionary and so it is exported by the data dll.
Perhaps send a message or debug of the connect string just before opening a file just to make sure the connect string is as expected. Go from there
Sean,
Thanks for your comment. I’ve used Ultimate Debug to confirm that the owner string is correct and consistent between single- and multi-app projects. It is consistent but only works with single app .exe projects, regardless of whether FM3 is used or not. The problem is clearly related to multi app solutions, including my production project, which has worked for years. I 'm stumped.
I’m stumped as well.
So why not go for something odd like check the build type (release/debug) of all apps. I have had thing work in one and not the other due to placement of code
Hi, have you tried to trace the application IO? I mean using the Clarion trace.
Yes, I have used trace with both my production and test apps. Here is an example.
https://www.dropbox.com/s/edajyr90bisptha/MSSQLTrace1.dblog?dl=0
Hi, have you solved your issue? The log shows that the connection string is empty. If you use a variable for this, it is probably not set or it is set too late (after the first attempt to access the database).
Thanks for writing. I have not resolved this problem. If I posted a log that didn’t include the connection string, that would be my mistake and I apologize for wasting your time.
I have generated another trace log, here on DropBox. This does include a valid owner string that works with single exe solutions, but not with multi-app solutions, regardless of whether the programs are built on my machine or another.
The global owner variables are declared as non-threaded in all applications involved.
I have tried 3 versions of SQL server Express (10.50.4042.0, 12.0.6118.4, and 15.0.2000.5) on two machines, always with the same results.
Hi Greg,
are you sure that the lack of the connection string in the previous log was not due to the fact that the variable storing Owner was empty when connecting to the database? Where/when you set the variable? And when you access the database for the first time?
Does the last log come from the working or non-working version? Why does it end at “connecting”? Nothing else is recorded afterwards? What happens in the application, any errors appear?
Can you provide two log files, from both versions (single- and multi-app), showing the same activity, best from the start of the application?
Regards,
Andrzej
In addition to Trace, UltimateDegug shows the proper content in the owner variable. Here’s the code:
UD.Message(‘Before OPEN(LocFMx:WorkFile)’)
UD.Message(’ GLO:Owner=’ & GLO:Owner)
ds_SetDebugging(1)
IF COMMAND(’/ShowConnectErrors’)
!
ELSE
LocFMx:WorkFile{prop:logonscreen} = false
LocFMx:WorkFile{prop:logintimeout} = 5
END
DISPLAY()
SETCURSOR(Cursor:Wait)
LocFMx:WorkFile{prop:owner} = GLO:Owner ! Set the FM3 table owner
OPEN(LocFMx:WorkFile) ! Verify valid connection by opening the FM3 file
The debug output looks good.
Before OPEN(LocFMx:WorkFile)
GLO:Owner=DEVELOPMENTGCF\SQLEXPRESS01,FM3
Is there an ERROR() or FILEERROR() after that open?
No ERROR() or FILEERROR(); apps become unresponsive upon executing the OPEN() statement; Task Manager shows steady, high CPU usage.
Hi Greg,
Your connection string doesn’t contain a username or password.
Does that mean you’re expecting the Login dialog and that dialog does not appear?
Or maybe you’re using the /TRUSTEDCONNECTION driver string?
Maybe try with full username and password?
I am relying upon Windows authentication. This works well will all single exe solutions; it is only the multi-app solutions that fail. I have tried using SQL Server authentication with no change in behavior.