Random error when loading project into Delphi XE6

Question

From time to time, when I load a project into the XE6 IDE, the following error occurs

This error results in the TZConnection component being removed from the Datamodule for some inexplicable reason. Note that the project has been loading without issue for ages and just out of the blue, this occurs.

Has anyone seen this before and know of a way of stopping it from occuring ? It also occurs with other components, not always the TZConnection component but mostly ZConnection.

Like I said before, this appears randomly. I could close project A, open project B then close it and return to Project A and bang!, the error occurs.

Any clues ? (note that this also used to occur in Delphi 2007)

Answer 1

Actually, it doesn't sound that inexplicable - it's probably caused by an exception occurring as the DataModule (or some form with db-aware components connected to it via properties) is being loaded into the IDE (see below). Have you tried checking that wherever your ZEOS .BPL files are located is on your system Path? Likewise any .BPLs they depend upon - see the "requires" clause in the .DPK file(s) for Zeos.

This sort of problem arises fairly frequently with flaky DB components, maybe more so than other types of component because db components more frequently involve linkages between datamodules and forms, e.g. when db-aware components on the forms are connected to others on the datamodule.

So, sometimes, whether this sort of problem shows up or not depends on the order in which the IDE will re-open them - try closing the project with only the dm open and then re-opening it. A bit of experimenting with which datamodules and forms are open in the IDE and in which order may help you pin down the problem. If/when you have a reproducible sequence of steps to provoke the problem, report it to the authors.

A fairly reliable way to determine whether the problem is being caused by an exception as a project loads is to run one instance of the IDE inside another. As long as the first ("outer") instance of the IDE has the debugger set to "Break on Language exceptions" it should be able to take you straight to the source of the exception (assuming it occurs, of course) when the project is loaded by the second instance. It may take a few goes to "catch it in the act" of course, but it is hugely satisfying when you manage to. Good luck!

Answer 2

Unlike MartynA I doubt this would be caused by an exception.

I would more likely expect such issues to be caused by windows path environment variable being too long.

Unfortunately still many component vendors and even some programs modify "windows path environment variable` to make their own files accessible by other programs.

And when windows path environment variable fails to provide sufficient information windows will try to find the files in default system directory which is C:\Windows\System32

So I would strongly advise checking the windows path environment variable to check its length.

The easiest way to do this is by simply starting the command prompt and typing in path directive or perhaps path >> D:\path.log to export the path environment variable information into a file for easier reading in case if it is long.

EDIT: BTW I just checked my path environment variable and I see that I will have to do some cleaning because it contains entries for both Delphi XE8 and Delphi XE 10 Seattle file locations even thou I have removed Delphi XE8 from my computer. Not to mention some entries from some programs that I have removed quite some time ago.

Answer 3

The Zeos libraries are themselves causing this problem.

To see why, and to fix it, use Delphi to launch a second instance of Delphi, and debug the issue directly.

I wrote a blog post showing exact steps here.

The key is to set the executable that will be run for your zeos package, be sure to build them in debug configuration, and then click the Run button on the Delphi IDE toolbar. A second delphi instance will start. Open the affected form but be sure to be using the IDE instance that is Being debugged as opposed to the one which is currently doing the debugging, when the exception occurs that is causing your component to delete itself, you will be able to step into the package code and see the problem.

I suspect a DLL-hell path issue. (Multiple copies of Zeos or other core BPL/DLLs in your path.)