HeidiSQL 3.0 Problems under Wine

Hello ..

I have just tried to use HeidiSQL on my Linux Box using wine. Most things work great, yet it seems it is not possible to transfer SQL Dumps directly to another DB Connection.

The first problem I stumbled upon was, that there was a Dialog Box complaining that MDAC Components would be missing as soon as I selected "Another host and database" on the Export Tables Dialog .

Ok, I installed them under Wine.

After I installed MDAC and retried, I got a cascade of error dialog boxes:

1 .) "Fetching Remote List of Databases" (No error, but it pops up first and stays open)
2 .) "Ein Objekt das dem angeforderten Namen oder Ordinalverweis entspricht, kann nicht gefunden werden" (German Error Message, Ansgar will understand :)
Clicking "ok" on the last dialog box produces
3.) "User cancelled" (Again, no error but stays open)
4.) "thr: Request 586093958 does not exist, cannot extract results"

After clicking these away, I get a final Error Message:

5.) "Access Violation at address 00404CBC in module heidisql.exe Read of Address 00000000"

I guess, HeidiSQL uses Microsoft Data Access Components for some kind of Interprocess Communication, and this fails under wine, which ultimately leads to a null pointer dereference.

If I use MySQL Front 2.5 under wine, the data transfer works as expected, so it must be a problem with new HeidiSQL code.

I don't know If this can be fixed in wine simply by installing some supplementing MDAC related components (maybe the JET Engine or something like that).

I am using the latest stable version of HeidiSQL 3.0. What also might be of interest is, that I installed HeidiSQL first, and MDAC later on.

By the way, Ansgar - thanks for MySQL Front and HeidiSQL, it's definitely the best Database Frontend I have seen so far.

bye,

Kai

The first problem I stumbled upon was, that there was a Dialog Box complaining that MDAC Components would be missing as soon as I selected "Another host and database" on the Export Tables Dialog.

HeidiSQL normally loads data using a "dataset", which is a component native to Delphi that keeps a local in-RAM cache of table data. The vanilla dataset component is not serializable, which is a necessary property for IPC for various reasons. HeidiSQL therefore transfers the data into an MDAC dataset, which is serializable. Data is then moved across to another process using shared memory. So that's why MDAC is necessary for exporting data to another open session.

If you get a dialog stating that MDAC was needed but not found, then everything is working perfectly from a technical point of view.

1 .) "Fetching Remote List of Databases" (No error, but it pops up first and stays open)

Capture the debug output that HeidiSQL produces during IPC (from both HeidiSQL windows!) and open a bug report. Under Windows, this is normally done using DbgView.

5.) "Access Violation at address 00404CBC in module heidisql.exe Read of Address 00000000"

None of the active developers on this project have any clue how to convert the above address into a Delphi source code location. If you find out, they'd be happy to help you further.

(Probably a case of faulty error handling, meaning this is a largely irrelevant follow-on error to whatever the previous erronous thing to happen was.)

I don't know If this can be fixed in wine simply by installing some supplementing MDAC related components (maybe the JET Engine or something like that).

Unlikely... I think the only thing used from MDAC is the dataset COM object.

I am using the latest stable version of HeidiSQL 3.0. What also might be of interest is, that I installed HeidiSQL first, and MDAC later on.

Should not pose a problem.

By the way, Ansgar - thanks for MySQL Front and HeidiSQL, it's definitely the best Database Frontend I have seen so far.

Thanks a lot!

The other team members hopefully know that they're also meant, not only me. :)

I tried to investigate a little bit.

Having Delphi 2005 available on a WindowsXP Machine, I gave it a try and tried to compile it. I wanted to have a stable version with more debug statements and debug symbols to try under Linux/Wine.

But then, I had lots of trouble getting the 3.0 stable source release to compile and run under Delphi 2005.

There were lots of "ExplicitWidth", "ExplicitHeight", "ExplicitTop", "Margin" and "Padding" Properties on some Components which my version of Delphi didn't seem to know. After I fixed that so that I was able to compile and start the program, I got another problem with this compiled version, which didn't resolve as easily: As soon as some Db query started, I got a modal dialog box (with a disabled cancel button) saying "Waiting for End of Query" or something like that, which never returned.

This is strange, since the (binary) stable 3.0 version works perfectly. I guess it's a D2005 problem, or a problem with some Components. ( I had some additional trouble since I already had SynEdit installed, but a much older version than you use)

Anyway .. next thing I tried was to locate the last version in SVN which did not use MDAC based IPC code. Looking through the SVN log, this seems to be Revision 232. I checked it out and tried a run at getting it to compile and work.

This time it was much easier - I replaced the ExplicitWidth etc. Property names, fixed some Imports and it works. I expect this version to work flawlessly under Wine. (I'm going to check this evening when I'm at my Linux box)

A lot of code updates happened since R232, and I guess there are some compelling reasons to use a newer version.

Assuming that MDAC based IPC is a lot of trouble under Wine, and also assuming that there really is a need for a good and free MySQL Frontend under Linux: - Is there any chance that the old way to do Inter-Connection Communication (i.e. one MDI Window per Connection, all in one Process) can be incorporated into the latest HeidiSQL Versions ? Or maybe an entirely different, less troublesome alternative (Sockets, Shared Files, Registry ??)

If not, maybe you can point me at the most important files / bugfixes / patches (unrelated to IPC) which should be incorporated into R232 to make this a relatively stable version of HeidiSQL for Linux users.

bye,

Kai

There were lots of "ExplicitWidth", "ExplicitHeight", "ExplicitTop", "Margin" and "Padding" Properties on some Components which my version of Delphi didn't seem to know.

A Subversion hook to deny commits with the Explicit---- properties were suggested at some point. Unfortunately, SF.net doesn't allow control over Subversion hooks.

Feel free to submit patches (upload files to the bug tracker fx.) to remove the Explicit---- properties!

After I fixed that so that I was able to compile and start the program, I got another problem with this compiled version, which didn't resolve as easily: As soon as some Db query started, I got a modal dialog box (with a disabled cancel button) saying "Waiting for End of Query" or something like that, which never returned.

Odd. Hard to come up with a clear answer with the limited amount of information given above (sorry).

Assuming that MDAC based IPC is a lot of trouble under Wine

Why would that be? Does not sound like it is much hassle to just install it.

and also assuming that there really is a need for a good and free MySQL Frontend under Linux

HeidiSQL is perfectly workable without MDAC, it's just the export-to-other-open-session feature that will give an error. You can always export to a physical file on disk and then import that in the other window.

Is there any chance that the old way to do Inter-Connection Communication (i.e. one MDI Window per Connection, all in one Process) can be incorporated into the latest HeidiSQL Versions?

I don't think so. Better to fix Wine if it doesn't emulate Windows properly, rather than going back to a more crappy version of HeidiSQL that doesn't tickle Wine, if you ask me.

(I'm pretty sure I've seen working window->window exports under Wine, so it might be a new issue in Wine or something?)

Or maybe an entirely different, less troublesome alternative (Sockets, Shared Files, Registry ??)

It's certainly possible to manually serialize a Delphi TDataset, instead of just having Delphi copy everything over to an ADO dataset. It's just that using the ADO thing is incredible easy. Copying and serializing is essentially 10 lines of code, whereas serializing a TDataset manually is probably more like 50 or 100. If you really want to get rid of the MDAC dependency, it's a very real possibility though. I've seen a number of examples over on the borland.public.* newsgroups.

If not, maybe you can point me at the most important files / bugfixes / patches (unrelated to IPC) which should be incorporated into R232 to make this a relatively stable version of HeidiSQL for Linux users.

I think that's a rather unproductive direction to steer in. Maybe you can convince some of the other team members to spend time on that..

If not, maybe you can point me at the most important files / bugfixes / patches (unrelated to IPC) which should be incorporated into R232 to make this a relatively stable version of HeidiSQL for Linux users.

I think that's a rather unproductive direction to steer in. Maybe you can convince some of the other team members to spend time on that..

I agree - rather unproductive. At least if the only problem is using MDAC in Export to oher host. Making a detour over a SQL-file is definitely the better alternative to reverting to a relative old version in which you'll find tons of other bugs.

Just to be complete here: The ExplicitXYZ properties were added in BDS 2006 and there is a bugreport at the Borland site complaing about random addings of those properties:
http://qc.borland.com/wc/qcmain.aspx?d=22615