I tried using the mysql package under WinNT and got some weird errors. Here's what I found out to solve the problem:

I couldn't get "make" to run - it always complained it cannot find /bin/sh, although I had copied sh.exe to /bin on every single drive I have...

So I tried compiling the demo program testdb.pp by manually calling ppc. Compiling was fine, but linking always failed "could not find -lmysqlclient". I patched "link.res" and changed the INPUT() section: changed "-lmysqlclient", "-lm", "-lc" to just "mysqlclient.lib" and called ldw directly - which works fine, but seems a little bit awkward to me.

So I investigated further and found out a slight error in mysql_com.pp: There is a section declaring the required libraries:

  {$linklib mysqlclient}
  {$linklib m}
  {$linklib c}

This may work under LINUX (haven't tried), but doesn't under WinNT. Changing it to the following lines makes it work perfectly under WinNT as well:

  {$ifdef win32}
    {$linklib mysqlclient.lib}
  {$else}
    {$linklib mysqlclient}
    {$linklib m}
    {$linklib c}
  {$endif}

(Leaving out the file extension ".lib" brakes linking for WinNT again.)

Maybe "make" takes care of this problem already - I don't know, since make does not work on my computer yet. On the other hand, if you apply this patch, you can compile it directly (mysqlclient.lib needs to be in a path defined by "-Fl" option, "libmysql.dll" needs to be in path at runtime of your program). Maybe someone can include this into the official distribution?

Bernhard Steffen

You must be using an older version of the mysql units;
the version that is currently in CVS contains the following code:
uses mysql_com;
{$ifdef win32}
Const mysqllib = 'libmysql';
{$else}
Const mysqllib = 'mysqlclient';
{$endif}
{$ifndef win32}
{$linklib c}
{$linklib m}
{$endif}

And I have tested this using mysql 3.22; Your using of the .lib library may be suitable for you personally, but in general it is preferred to use the libmysql.dll version; in that case the extension '.lib' is not needed.

As you can see, the problem has been remedied.

Michael.

There is probably some make.cmd (for OS/2 with bash IIRC) somewhere in your path, which is a known problem with NT.

type "make.exe", or removed the make.cmd

The .CMD extension is used by Os/2's own command prompt as far as I remember.

- noah silva

The .CMD extension is used by Os/2's own command prompt as far as I remember.

But do OS/2 specific batchfiles have /bin/sh as first line???

Subject: Re: [fpc-pascal]mysql package under WinNT To:
Date sent: Sun, 11 Mar 2001 18:40:01 +0100 (CET) From: (Marco van de Voort)
Send reply to:

> The .CMD extension is used by Os/2's own command prompt as far as I > remember.

In fact, it's an extension for batch files (scripts) which should be handled with CMD.EXE (which is a command interpreter in both OS/2 and WinNT, where it's supported as well).

But do OS/2 specific batchfiles have /bin/sh as first line???

No, never. OS/2 batch files are of two basic types - one is very similar to DOS batch files (i.e. only command shell internal commands and calls to external programs may appear there), the other must start with /* (start of a comment in REXX programs) and then it's interpreted with the integrated REXX language interpreter.

Have a nice day

Tomas Hajny, on Internet
in urgent cases

To 's reply:

That's the code I found in mysql.pp - mysql_com.pp had the other one. I downloaded these files just a couple of days ago from freepascal.org. File dates of mysql.pp and mysql_com.pp within the zip file are 2000-12-03.

Your using of the .lib library may be suitable for you personally, but in general it is preferred to use the libmysql.dll version; in that case the extension '.lib' is not needed.

Before I received your reply, I tried leaving out the {$linklib} section at all in mysql_com.pp - it worked. I guess, this is because it is already included in mysql.pp, so the linker knows where to look? So basically, I just have to fix my version of mysql_com.pp.

... which I just did (copying the lines from mysql.pp to mysql_com.pp), but:

But I just ran into another problem: When using the demo program "testdb.pp", everything works fine. If I leave out the section at the beginning of the program ("if paramcount=1 then begin Dummy:=Paramstr(1) ..."), my program halts with runtime error 103 (file not open). But since I ran this program without a command line parameter, these statements should never get executed, so it shouldn't make any difference if I leave them out.

Later this evening I tried to set up my own mysql interface unit, since I would like to have an easier error handling (internal error handler gets called automatically after each call to mysql) as well as automatic connection opening (and closing).

Now my program halts shortly after the mysql_connect call. A first "writeln" statement will get printed, subsequent "writeln" won't, even if there's no other function call in between. Program halts with either "access violation: address 00000000: read of 0000000" (WinNT error popup) or "runtime error 103" (fpc; first writeln statement after call to mysql_connect).

Any ideas? I'm using Windows NT 4, FPC 1.04 (downloaded 2001-01-01). I've no debugger set up, but I'm compiling my program with "-gl -gh -ddebug". heaptrc says "No heap dump by heaptrc unit".

Any help appreciated. Thank you.

Bernhard

P.S.: Connecting to mysql via the mysql client works fine, so mysqld is up and running. I'm using 3.22.32 (Ver 9.38)

Hi,

I've checked MySQL units, as a part of
packages.zip, and I have to say AGAIN (for Michael VanCanneyt ) there is a bug (or problem) which prevents it from working under win32 and solution is know now for, approx., one year. Test program works fine - because of little db. But if you have bigger db it fails. The problem (not real bug) in function declaration under win32 all functions MUST be stdcall instead of cdecl.

If you want working libs (mysql 3.22.x) I can send it to you.

Mirek Novak

Bernhard Steffen píše:

It has been changed.
Calling convention on Win32 is now stdcall, cdecl on Unix systems.

Michael.

Michael and Mirek, thanks for your help.

I tried the following:

- changed all "cdecl" to "stdcall" in mysql.pp and mysql_com.pp
- added the correct {$linklib...} statements in mysql_com.pp
- changed the first parameter of my function call of mysql_connect() from a local var on stack to a global var within the unit (seems strange to me, but otherwise I will still get the error)

Now my program runs fine, every query gets executed etc. without any apparent error.

... but still one thing doesn't work:

As soon as I run more than one query, I will get an WinNT error popup when calling mysql_close():
"Microsoft Visual C++ Debug Library
Debug Assertion Failed
Program: <path> test.exe
File: dbgheap.c
Line: 1011
Expression: _CrtIsValidHeapPointer(pUserData)
"
- If I do an (A)bort, the program dies silently, no other command after mysql_close() gets executed
- If I do a (R)etry, I get yet another NT error: "unknown software exception" (0x80000003) at position 0x100278AB; after that, my program quits silently
- If I do an (I)gnore, program will quit with an runtime error 216 at the same position and a call stack trace gets printed

I'm doing queries in the way as described in "testdb.pp", ie *** mysql_connect
*** mysql_select_db
*** one or more:
- mysql_query
- mysql_store_result
- one or more: mysql_fetch_row
- mysql_free_result
*** mysql_close

Anything I forgot?

Since I updated, I'm now using MySQL 3.23.34 (debug version of client lib) on WinNT. Program is compiled with -gl -gh.

Again, any help appreciated!

Bernhard

Hi,

Probable solution of your problem is:

- use 3.22.* version of client, because mysql.pp lib _is_ for 3.22.* client. There are some differences, in structures defined in client header, between 3.22 and 3.23. I think /don't know exactly/ you can use older client with new server but for to be sure ask , for examle via "MySQL mail list" .

Mirek Novak
Anima Publishers
www.auto.cz

Bernhard Steffen píše: