Access behaving badly, again. (3 Viewers)

[John Sh]

For a while, Access seemed to be behaving until I changed the text below,
from

Me.btnShow.Caption = "The Family '" & Me.txtFamilyIn & "'" & vbCrLf & _
                         "Is not on the Taxon list." & vbCrLf & vbCrLf & _
                         "Please check the hispid sheet, for the correct Family." & vbCrLf & _
                         "Click ""Add to Taxon"" to include."
to
Me.btnShow.Caption = "The Family '" & Me.txtFamilyIn & "'" & vbCrLf & _
                         "Is not on the Taxon list." & vbCrLf & _
                         "Please check World Flora Online," & vbCrLf & _
                         "or the hispid sheet, for the correct Family." & vbCrLf & _
                         "Click ""Add to Taxon"" to include."

From the moment I altered that text, two of my small forms disappeared behind other forms while other small forms displayed normally.
Today, I did a compact and repair using Access 365 on a Windows 10 machine. This made no difference to the behaviour.
Access was also only loading partially on this machine but an older copy of the database ran normally.
This would indicate corruption somewhere. How best to determine exactly where?
An mdb file was created, and rather than have an error log, it had a fully operational copy of the database.

I am a little bit suspicious of the university system, since some of this behaviour seems to be coincident with the start of the first semester but some of it is definitely connected to my, independent, system at home.

The attached forms "getTaxon" and "Max_Box" have popup off to display on top while "addTaxon" has popup on.
The larger forms with which they are associated are all popup off, modal off.

 

[June7]

How do you expect us to test without data for bound forms? No tables were included.

Also, compile error due to undeclared variable oDB.

 

[tvanstiphout]

I am 99% sure the issue is NOT with the code change you showed.
Did you try decompiling the application?
When you copy an ACCDB from Uni to Home or vice versa, the versions may be different enough that fresh compiled code is needed.
Search online for "Access decompile" to learn how to do it.

 

[John Sh]

I am 99% sure the issue is NOT with the code change you showed.
Did you try decompiling the application?
When you copy an ACCDB from Uni to Home or vice versa, the versions may be different enough that fresh compiled code is needed.
Search online for "Access decompile" to learn how to do it.

Thanks Tom.
I will give it a try, but what am I looking for in the decompiled code?
I agree that the string change is not the problem but it seems to have triggered the change in behaviour.
Almost as if the system was waiting for any change in the code to trip it into fail mode.
The code compiled at the uni was run on the same system with the same, or very similar, behaviour.
John

 

[John Sh]

How do you expect us to test without data for bound forms? No tables were included.

Also, compile error due to undeclared variable oDB.

Understood.
The object "odb" is declared Public in a module. I should have noted this. oDB simply replaces "set db = currentdb" and uses the same object rather than creating a new object each time. Re DevHut, I think.
Re no tables, it's not that simple. I would have to include a goodly portion of the complete system to have these forms work.
They both rely on data from other forms as well as functions and sql strings included in modules and various tables in the back end.
The front end is 50MB and the back end is 70MB.
John

 

[tvanstiphout]

> what am I looking for in the decompiled code?
Nothing. Decompiling throws away previous compiled state of each form and module (the P-Code that is run by the VBA runtime). Next time the code is run, Access will automatically compile it again, rather than re-using the possibly bad previous compiled state. This all happens invisibly behind the scenes.

 

[John Sh]

Thanks.
Nothing ventured, nothing gained.
John