I have a strange issue where most of the time when inserting a record on a form the parent browse will show an ‘Error: (File Not Open (37))’ error message. This sometimes doesn’t happen but only rarely. Please see the attached video for an example of the error occurring when adding a new ‘Person Photo’.
As you can see in the video the record is inserted successfully into the MSSQL database and shows in the list for a millisecond before the ‘Person Involved’ window is closed.
The insert is happening on a form opened from a few parents browses/forms:
– Incident Report Log (browse)
— Edit > Report Detail (form)
---- New > Person Involved (form)
----- New > Photo (form).
Only the ‘Person Involved’ and ‘Photo’ procs contain the table in question ‘dbo.IncPersonPhotos’. Things I have tried:
Adding the table to the ‘Report Detail’ and ‘Incident Report Log’ procs.
Turned off the ‘Defer opening files until accessed’.
Adding access:IncPersonPhotos.open() and access:IncPersonPhotos.UseFile() in various places in the ‘Person Involved’ form.
Ripping my hair out.
But none of these have worked. Appreciate any help as this has stopped me from progressing for a few days now.
Hi, you gave too little information about how your application works, what you use, etc.
The “Photos” browse on the “New person involved” form - does it use a standard ABC Browse Class?
Is the “Add new person photo” procedure a standard ABC form? How is the “IncPersonPhotos” table handled on this form? Is it opened / closed using File (or Relation) Manager? How is the record added?
It seems that the table is closed when the form closes.
Is the record actually added to the database?
Don’t you have explicit calls to open / close / usefile anywhere in your code?
Is the “New” button an insert button added as control template?
I would also suggest to use the Clarion Trace, to make sure that there are no unhandled errors.
I notice in the log that SYSID = 0 on the Add
I assume that SYSID is the primary key?
Wondering if sysid needs to be added as a hot field in the browse?
perhaps something else has gone astray creating it?
thanks for the log, but it only contains a small piece of information. Was the logging turned on at runtime only on the IncPersonPhotos table? I would need the log to include the start of the UpdIncPerson procedure. E.g. there is no activity from the “photos” browse on UpdateIncPerson before opening the form. It would be best to activate the complete tracing globally, before starting the application.
The most suspicious place for me at the moment is - “Select a known person” lookup.
It is likely that you have the same VIEW in this procedure as in UpdateIncPerson, and closing “Select personnel” closes the view!
The key here is information about which Bob Foreman wrote ages ago and which is probably still valid:
FILEs and VIEWs declared locally are, in fact, static objects (this was so in pre-C6 and is remaining so in C6.x).
If this were confirmed, you would have to use aliases (the right Clarion way for such cases) or manually handle blocking the VIEW closing when exiting the “Select personnel” lookup.
By the way, maybe someone was intrigued by this behavior - this happens due to the imperfections (inconsistencies) of error checking in the Browse class. After closing the Form, browse class performs the ResetFromAsk method, and during filling the queue, our error occurs - a message is shown and the event CloseWindow is posted.
But the method continues and finally calls the ResetFromView where view is reopened and the last record is retrieved succesfully, but finally comes the handling of the CloseWindow event and the window closes.
The ‘Select a known person’ lookup (SelectPersonnel) is using an alias on a different table than the UpdateIncPerson form table. SelectPersonnel has a browse on the IncPersonParent2 table (alias of IncPersonParent) which is the parent table. UpdateIncPerson is updating the IncPerson table which is the child table with a many to one relationship to the IncPersonParent table.
I did notice that SelectPersonnel had the IncPersonPhotos2 table (alias of IncPersonPhotos table) in it’s file definitions so have removed that but the issue still occurs.
The log would be too big to include tracing globally, so I’ve activated the tracing in the UpdateIncident2 form (Report Detail form in the original post) and here are the logs:
text files compress very well. It would be better to do “global” logging, compress the log and attach the zip file here or share it via some network drive.
This partial trace lacks too many informations. E.g. I still don’t see any activity on the IncPersonPhotos table before opening the IncPersonPhotos form.
Hi,
Are you connecting via Wi-Fi? You will see this on Wi-Fi dropout.
Also with MSSQL you may get disconnections from any user number limitations or various configured settings, or an adminsitration person closing a connection.
I’m not sure what happens on a very slow network timeout but it probably does result in something.
It’s worth making sure the issue is not Network/SQL Server related when your code normally functions perfectly well.
Hope this is helpful, Jim
Hi Trent,
That’s actually really interesting. This issue has been seen occasionally by others using standard ABC based templates etc. I can see from what Andrzej says there may be a problem in the Browse class. I wonder if SV are aware and looking into it? One of the reasons we use Clarion is the expected reliability of the built in library code.
Regards, Jim
Couldn’t figure out how to fix it so changed the Photos browse in UpdateIncPerson to use a different generic In-Memory table as a workaround which is working successfully.
Thank you to all that helped. The MSSQL Trace Log link has been removed.
- this happens due to the imperfections (inconsistencies) of error checking in the Browse class. After closing the Form, browse class performs the ResetFromAsk method, and during filling the queue, our error occurs - a message is shown and the event CloseWindow is posted.