Is there a way to suppress the File Access Error Message and the subsequent Halt when the application is unable to open a SQL Table? I would like to grab the error and allow the application to either continue without opening the table or gracefully shutdown.
Here is an image of the error I would like suppress
Good evening, I am newly signed up but have been lurking on here for awhile. I am on a bit of a time crunch and don’t have the time to experiment so I thought one of you may have already ran into this situation and found a solution. I saw this post and figured this was a good time to jump in.
Let me give you a little background on the situation. We use Clarion 6 and we handcode, we do not use ABC templates. We are wanting to migrate from .dat/tps files to MSSQL. The current .dat/tps tables are in use 24/7 (manufacturing plants). We want to write to both the .dat/tps files and the MSSQL tables at the same time as the first step in this transition.
We attempted this last year and the workstations on the production floor threw errors (This process works correctly in both our Dev and Tst environments.) There was ‘panic in the streets’ and they immediately ‘rolled back’ to a previous Clarion build and did not provide us with any feedback. I have a slight opening in my work load and have been assigned to revisit this week.
In order to generate feedback but not cause the panic, I am logging any error that is received, setting a global variable and if the global variable is set to false than the code that writes to the tables will not attempt to write to MSSQL. All of this is working.
The problem is that the user receives the Microsoft SQL error and I have not been able to figure out a way to suppress this.
My code is an extension that sets the base variables and then a .inc that pulls together the login info, server name, etc. I then do a simple OPEN() call. Immediately afterwards I have Error() handling which works fine but of course it doesn’t handle the Microsoft error. Is there any way to suppress these?
Hi Cindy
In my experience, errors in prod that are ok in test is almost always security permissions of one form or another.
Unfortunately with SQL the possible causes are legion and restricted to your site.
Cindy,
Just to let you know, the error that I get comes from the ABC File Manager class. This occurs when I do Access:Table.Open or Access:Table.TryFetch. According to some people that I have talked to, the only way to suppress this error is to modify the File Manager class, which I do not want to do. What I have done is write a small C# program that I call SQLPing and test the Database connection prior to performing the Open or Fetch, and if the Ping fails then I do my error handling.
Thanks for letting me know. I was tempted to create a new app using the ABC templates and use that TryOpen but it doesn’t sound like that would work either.
These are the errors I receive in my testing (Dev) and I am purposely passing the incorrect password to make it fire. I added your suggestion for the PROP:LogonScreen but it didn’t make a difference.
I have been able to get an agreement with the manufacturing IT to run our application on an unused machine in production tonight in order to receive accurate feedback. If that falls through, then I guess I am going to write up a web service and make a call to it.
Small function that checks server status without any error message;
SETCURSOR(CURSOR:Wait)
SQLQuery{PROP:LogonScreen}=False ! Any SQL based table
OPEN(SQLQuery,0)
IF ERRORCODE() OR FILEERRORCODE() THEN
Loc:ServerStatus=Level:Fatal
ASSERT(~ERRORCODE())
!HALT ! If you want to stop program execution
ELSE
CLOSE(SQLQuery)
Loc:ServerStatus=Level:Benign
END
SETCURSOR()
RETURN(Loc:ServerStatus)
Our .dct is at it’s max so I did not add the table to the .dct. I connect to at Dummy table just to complete the login but from that point I use all Stored Procedure calls. But thank you for the recommendation.
So far, SerhatSatir’s recommendation is working. Testers are running the code through it’s paces right now and will go into Production next week and I will know for sure if it was successful.
This is Clarion 6. It is my understanding this was resolved in future Clarion releases.
With Clarion 6, there is a limit on the number of objects that can be in the defseg. You can have multiple defsegs if you are using the Capesoft templates but I don’t remember the limit on those, maybe 3 or 4.
Technically, SerhatSatir’s recommendation worked. Unfortunately another developer had added a SP call in a linked application and didn’t utilize my template/include file where the SQLQuery{PROP:LogonScreen}=False was stored. So, Production got a nice jolt this morning when processes hit his code.
But the logging I added pointed out the issue with the connection and we were able to get it resolved and production is running smoothly and connected to the database.
We’ve also had to deal with this before. The solution I used was to check the SQL connection outside of Clarion’s connection, by using ADO. In our case, the connection is checked before the Clarion connection is established, which helps to circumvent unwanted Clarion messages. I don’t have a concise portion of code to share yet, but I can post if here if you still need it?
Two other ideas that may be helpful:
Suppress Clarion messages until after the Clarion connection has been done, by using something like system{PROP:MessageHook} = address (MyMessage) where MyMessage is your own function to trap Clarion messages. The Clarion help has a good description of this.
If you were using the ABC classes, there is a way to override the methods in the global embeds. This way helps you to trap the error message during the Open method.