------_=_NextPart_001_01C5DEA0.4017B794
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Platform: WinXP Pro w/VS 2003/VC++ 7.1 - All service packs installed.

=20

I have a COM object I am building which accesses both a Jet (Access)
database and a MySQL database. I had been using ADO for both but kept
running in to errors accessing MySQL that gave me no information about
what actually went wrong. I felt the lack of info in the errors was
likely due to the fact that my calls were going through many layers: ADO
to OLEDB to ODBC to MySQL. I figured direct access to MySQL would be
better all around, so I downloaded mysql++ and got it to build just
fine. I read the tutorials, looked at the samples, and then went to
convert my code. =20

=20

The first problem I ran into was that both ADO and mysql++ define Field,
Fields and Connection classes. I did not think this would be an issue,
because I could just not use the "using mysqlpp" directive and reference
all of the mysql++ names explicitly, but I was also trying to use the
nifty SSQLS functionality, and it turns out that the sql_create_x macros
will not compile unless "using mysqlpp;" has been declared. Note that I
tested my theory by removing the using directive from custom1.cpp and
making namespace references explicit and I got the exact same compile
errors as my COM object did. Some of the solutions I thought about
were:

=20

1) Try to fix the sql_create_x macros (not likely since I am not very
proficient in Perl)

2) Try to isolate all of my references to ADO and mysql++ from each
other (this would be quite a bit of work)

3) Rename the Field, Fields and Connection classes (tried this, but
started getting nasty linker errors in my COM object - the lib built
fine, though - and those can be very tricky to track down)

4) Abandon using SSQLS and go with straight mysqlpp and reference all
symbols explicitly.

5) Abandon mysql++ altogether.

=20

Having pretty much either ruled out or tried 1-3, and feeling that #5 is
a last resort because clearly many people use this library, so I am
certain I can get it to work, I am currently attempting #4.

=20

However, I thought I would still report the issue here in the hopes that
someone has a simple solution to my problem. Short of that, I would at
least like to report it as a potential bug so that it could be addressed
in a future release (again, if was better at Perl, I would fix it and
then report the problem along with my potential fix). =20

=20

Any comments/suggestions/etc. will be greatly appreciated.

=20

Thanks,

Dave Parker

IT SystemWorks

=20


------_=_NextPart_001_01C5DEA0.4017B794--

On Mon, Oct 31, 2005 at 08:53:58PM -0800, David Parker wrote:
That's a bug! :-)

Try this patch. You'll need to download it from the following link, as
the mailing list won't accept patches this big.

http://www.netdirect.ca/~cdfrey/mysq...amespace.patch

This patch changes the custom.pl and the custom*.cpp examples to use
the mysqlpp:: namespace explicitly, which should fix your problem.

The makefile should regenerate custom-macros.h for you, but keep an eye
on it. This patch only changes the perl script.

Enjoy,
- Chris


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Thanks for the quick response! I have not tried your patch yet (I
will!), but I did come up with another solution once I gave it some time
to think it over. My other solution is to use the rename() predicate of
the #import directive that I am using to generate the msado15.*
interface files to rename ADO's Field, Fields and Connection objects.

Thanks again.

Dave Parker
IT SystemWorks

-----Original Message-----
From: Chris Frey [mailto:cdfrey (AT) foursquare (DOT) net]=20
Sent: Tuesday, November 01, 2005 11:27 AM
To: plusplus (AT) lists (DOT) mysql.com
Subject: Re: mysql++ and ADO namespace conflict

On Mon, Oct 31, 2005 at 08:53:58PM -0800, David Parker wrote:
That's a bug! :-)

Try this patch. You'll need to download it from the following link, as
the mailing list won't accept patches this big.

http://www.netdirect.ca/~cdfrey/mysq...amespace.patch

This patch changes the custom.pl and the custom*.cpp examples to use
the mysqlpp:: namespace explicitly, which should fix your problem.

The makefile should regenerate custom-macros.h for you, but keep an eye
on it. This patch only changes the perl script.

Enjoy,
- Chris


--=20
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:
http://lists.mysql.com/plusplus?unsu...yrad (DOT) com



--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Chris Frey wrote:
Go ahead and apply it to HEAD.

Please check in the custom.pl and the examples sides separately. They
are separate things, right? I mean, it seems that you changed the
examples to no longer hoist MySQL++ symbols into the global namespace
just to illustrate the point. If so, it's not really part of the
custom.pl patch.

I may release this plus a few other pending things as 2.0.7, even though
I'm working on getting v2.1 under way.

Not on Windows; that's part of the autotools build system only. He'll
need to run Perl on custom.pl manually.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

On Tue, Nov 01, 2005 at 02:43:17PM -0700, Warren Young wrote:
Yes, they are separate... the examples change was only for testing.

I've committed them separately.

- Chris


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw