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

 

[The_Doc_Man]

I will give it a try, but what am I looking for in the decompiled code?

Nothing, because DECOMPILE merely removes the binary stuff that is behind-the-scenes of the actual VBA.

When you compile code for a module, the VBA compiler (technically, pseudo-compiler) puts the result of the compilation into a binary large object, lovingly known as a BLOB. When you modify VBA code that has been compiled already, Access senses that the VBA text edit date is newer than the BLOB's compile date and so selectively removes the obsolete BLOB - then replaces it wish a newly compiled BLOB. Totally transparent to you.

What the DECOMPILE option does is remove ALL of the BLOBs. Which means that when you next attempt to execute anything, the date on the VBA code is now newer than the date on the BLOB (probably 0, which translates to 30-Dec-1899). So Access recompiles everything. This is good because if your problem was a type of corruption in the BLOBs, you want them ALL replaced. But you never see any of that. What you DO see is that everything that HAD been corrupted just might be corrected by the automatic recompilation.

Before you ask... you cannot do this to a .ACCDE or .MDE file because the VBA code isn't there. Decompiling a .MDE or .ACCDE - if it is allowed to happen - destroys all of the code. But in an .MDB or .ACCDB that has recently been compiled, the VBA text form of the code is still in the general or class modules and the BLOBs are created somewhere so they can be conveniently called when code needs to be executed..

So... what you are looking for in the decompiled code is that the problem goes away when you next try to execute the code.

 

[John Sh]

Thanks DocMan.
A very comprehensive and easily understandable explanation.
I have decompiled the accdb following the advice here, https://www.devhut.net/ms-access-decompile-a-database/.
I reopened the files in a new, blank, database and the problem still exists.
I have scanned my computer for virus/malware and found nothing.
I am seriously considering reinstalling Windows 10 and purchasing a later version of Access.
The fact that these errors are happening on two, isolated, machines however, makes me think there is some obscure corruption in the code even though the compile process runs without error.
That said, I haven't tried to decompile and recompile on the uni computers. I may not even have access rights to the msAccess.exe file.
I'll have a chat to the IT people.

If I seem a bit vague about some of the more technical bits, I did half a semester of software engineering 101 about 20 years ago.
I do have a better than basic knowledge of things computer but some of the nitty gritty takes a while to sink in.
John

 

[The_Doc_Man]

The fact that these errors are happening on two, isolated, machines however, makes me think there is some obscure corruption in the code even though the compile process runs without error.

If you have the ability to open and update data in an Access .ACCDB file, you have sufficient permissions to DECOMPILE. Permissions are a Windows whole-file concept. If you can modify an Access DB, you can modify any part of that DB including the BLOBs.

When you have a problem on two machines out of a larger bunch that doesn't have the problem, that is either a different setting or an O/S or Access or library version difference. I personally hate this class of problem because you need to meticulously (read "tediously") seek the difference. As Elmer Fudd would say in MANY Looney Tunes cartoons, ... "To make wabbit stew, first you must catch the Wabbit." And he set a good example in those cartoons as to just how difficult it is to do that.

 

[MsAccessNL]

When you change code and save it, other settings of your form (in design mode), will be saved to. I don’t know about the z-order, but the size and position can be changed. If you have multiple forms open in design mode, access may ask you to save all forms (with changed properties and size, even if you haven’t changed them by hand). I don’t think that the z-order problem is a corruption error. Try to move the “hidden” form in front or next to the “blocking” form, right click, save both forms, close them and open again.

 

[John Sh]

If you have the ability to open and update data in an Access .ACCDB file, you have sufficient permissions to DECOMPILE. Permissions are a Windows whole-file concept. If you can modify an Access DB, you can modify any part of that DB including the BLOBs.

When you have a problem on two machines out of a larger bunch that doesn't have the problem, that is either a different setting or an O/S or Access or library version difference. I personally hate this class of problem because you need to meticulously (read "tediously") seek the difference. As Elmer Fudd would say in MANY Looney Tunes cartoons, ... "To make wabbit stew, first you must catch the Wabbit." And he set a good example in those cartoons as to just how difficult it is to do that.

Elmer Fudd was wise beyond his years,
My next approach is to start a new database using some of the existing code and try to cause the problem to show itself.

The uni problem is that while I have access to the operation of msAccess I may not be able to address msAccess.exe to use the command line.
It depends on how the uni software centre disperses the apps.

 

[John Sh]

When you change code and save it, other settings of your form (in design mode), will be saved to. I don’t know about the z-order, but the size and position can be changed. If you have multiple forms open in design mode, access may ask you to save all forms (with changed properties and size, even if you haven’t changed them by hand). I don’t think that the z-order problem is a corruption error. Try to move the “hidden” form in front or next to the “blocking” form, right click, save both forms, close them and open again.

I haven't given the Z order any thought but it's certainly worth considering.
Thank you
John