MySQL 4.x, MyODBC 3.51 or so, and #tables

Hello all,

To the MySQL users in the group, have any of you seen any problems with
#tables after an upgrade?  If you are keeping up with GA releases and
_not_ having problems, then I would very much like to hear about it.  I
have a hunch that the problem is trickier than it appears.

FWIW, I installed 4.1 (GA) and the current MyODBC, then attempted to
uninstall and downgrade.  The problem persists.  I have "identical"
machines and will probably try one of them soon.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

I have MySQL 4.1.7 running on XP with ODBC version 3.51.06. After
resolving the 'old client'-issue by setting the old type password for
some users, I can see no problems so far.

I did a fresh install for this system recently and installed this MySQL
version. No upgrade of an older version. I only copied the data from the
old machine.

Regards,

Nico

Bill Schwab wrote:

Nico,

> I have MySQL 4.1.7 running on XP with ODBC version 3.51.06. After
> resolving the 'old client'-issue by setting the old type password for
> some users, I can see no problems so far.

Thanks for mentioning this - I hit (presumably) the same problem with
MySQL-front 2.5(??) and would emjoy being able to use it, at least until
the Administrator is less buggy.

With appologies to you and the dead horse, do you succcessfully call
#tables?  I ask because that was the only problem I saw.


> I did a fresh install for this system recently and installed this MySQL
> version. No upgrade of an older version. I only copied the data from the
> old machine.

How did you install it?  I used the MSI file and the configuration
wizard, and can't help wondering whether that zapped me.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> Thanks for mentioning this - I hit (presumably) the same problem with
> MySQL-front 2.5(??) and would emjoy being able to use it, at least until
> the Administrator is less buggy.

I use the MySQL Control Center, which works ok.

> With appologies to you and the dead horse, do you succcessfully call
> #tables?  I ask because that was the only problem I saw.

Yes, this works fine here.

> How did you install it?  I used the MSI file and the configuration
> wizard, and can't help wondering whether that zapped me.

I downloaded and installed the mysql-4.1.7-win.exe, which is the same I
think? Then I applied the "password patch" for some users as described
in http://dev.mysql.com/doc/mysql/en/Old_client.html.

I only use the MyISAM style tables. Maybe there is a problem with the
other formats like InnoDB? While thinking about that I created quickly
an InnoDB table and tried the #tables method again on a DBConnection.
All goes well. No clue what could go wrong on your side.

Nico

Nico,

> I downloaded and installed the mysql-4.1.7-win.exe, which is the same I
> think? Then I applied the "password patch" for some users as described
> in http://dev.mysql.com/doc/mysql/en/Old_client.html.

Odd, but I don't see a .exe file, though I thought I saw an option for
it somewhere.  Now, I see a .zip file which contains a 38MB setup.exe.
I installed using the essentials msi file, and then used its
configuration wizard.

Did you run the wizard or do a manual configuration?


> I only use the MyISAM style tables. Maybe there is a problem with the
> other formats like InnoDB? While thinking about that I created quickly
> an InnoDB table and tried the #tables method again on a DBConnection.
> All goes well. No clue what could go wrong on your side.

To be honest, I will need to check the problematic machine to be certain
of the table type - I don't do anything specific to control it, and so
should be getting MyISAM (I think).

Thanks for checking.  It's nice to know that it can work.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> Odd, but I don't see a .exe file, though I thought I saw an option for
> it somewhere.  Now, I see a .zip file which contains a 38MB setup.exe. I
> installed using the essentials msi file, and then used its configuration
> wizard.

You are right. It was the mysql-4.1.7-win.zip file with the Setup.exe
(37.669 kB) in it which I renamed to mysql-4.1.7-win.exe.

> Did you run the wizard or do a manual configuration?

I ran this Setup.exe which comes up with the wizard. This is what you
mean, I think. It gave me some options about the type of server and the
type of tables etc.

I didn't do anything special and also have no experience with MySQL to
work differently on specific cases. Very strange. Maybe you have some
older DLL's lying around (cygwin, mysql)?

Good luck,

Nico

Nico,

> I only use the MyISAM style tables. Maybe there is a problem with the
> other formats like InnoDB? While thinking about that I created quickly
> an InnoDB table and tried the #tables method again on a DBConnection.
> All goes well. No clue what could go wrong on your side.

I have gone around with this again, and it appears to be a problem in
the way MySQL/MyODBC reports the catalog for things that don't have one;
at least that fits the observations so far.

I can get it to run by adding a check to DBField>>asString.  The
offending buffer is #[ 0 ], which looks a lot like the empty string
mentioned in

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcsqltables.asp

All would be well, except that the field thinks it has a length of 9, so
the copying bytes step complains.  It seems likely that ODBC is
incorrectly passing a length of 9 along with the empty string.  I am
hesitant to leave my "fix" in place because it could cause silent
failures during other tasks.

There is, of course, the small detail that this all works for you.
Which language are you using?  Anything else that might affect the code
that you are running?  XP is another source of possibly newer code that
might explain the difference; the machines giving me trouble have all
been running 2k sp3 or sp4 (I think on one box).

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Nico,

> All would be well, except that the field thinks it has a length of 9, so
> the copying bytes step complains.  It seems likely that ODBC is
> incorrectly passing a length of 9 along with the empty string.  I am
> hesitant to leave my "fix" in place because it could cause silent
> failures during other tasks.

FWIW, the method below appears to work around the problem, and hopefully
with minimal impact when it is not needed.  You hinted earlier at the
idea of an old or new DLL somewhere.  Just a hunch, but I suspect that
it is a newer one that is not being overwritten as I install older and
older versions in an attempt to get back to normal.  I also admit to
uninstalling either MyODBC or MySQL, but not necessarily both at every
stage.

Have a good one,

Bill



!DBField methodsFor!

asString
        "Private - Answer the receiver's buffer as a <String>."

        #wksDangerous.
        "( buffer = #[0] ) ifTrue:[ ^String new ].
        The outer test avoids doing the string comparison on
        every field.  The test against TABLE_CAT is to test the idea
        that catalogs are to blame, and to avoid unnecessary side effects."
        buffer size = 1 ifTrue:[
                column name = 'TABLE_CAT' ifTrue:[
                        ( buffer = #[0] ) ifTrue:[ ^String new ].
                ].
        ].

        ^buffer copyStringFrom: 1 to: self length
! !
!DBField categoriesFor: #asString!converting!private! !


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Nico,

> FWIW, the method below appears to work around the problem, and hopefully
> with minimal impact when it is not needed.  You hinted earlier at the
> idea of an old or new DLL somewhere.  Just a hunch, but I suspect that
> it is a newer one that is not being overwritten as I install older and
> older versions in an attempt to get back to normal.  I also admit to
> uninstalling either MyODBC or MySQL, but not necessarily both at every
> stage.

Enabling the No Catalog feature appears to have fixed it (without my
workaround) on the machine that first suffered from this problem.  It is
no longer running 4.1.x, but the MyODBC version is more current than
anything I am using elsewhere.  I will double check it and try other
machines tomorrow.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Hello all,

> Enabling the No Catalog feature appears to have fixed it (without my
> workaround) on the machine that first suffered from this problem.  It is
> no longer running 4.1.x, but the MyODBC version is more current than
> anything I am using elsewhere.  I will double check it and try other
> machines tomorrow.

Confirmed.  I suspect this points to a bug in MyODBC, but have no proof
as yet.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]