Warren Young wrote:
> Drew Vogel wrote:
>> If I
>> select all of the columns in the table (named, not using *), the last
>> column (wpc_bludgeoning) is corrupted. When I select just the four
>> wpc_* columns, the data in the third column (wpc_chopping) corrupted.
>> In both scenerios, it corrupts the data in the last or third rows,
>> respectively, for both rows in the result set.
>
> Sounds like you have a memory bug somewhere. While it's possible that
> it is in MySQL++, you'd think that someone else would have run into
> something this blatant before.
>
> If you're running on a Linux or OS X machine, try running your program
> under valgrind. If on Windows, you may only have the choice of
> commercial programs like Bounds Checker.
>
I'm not sure I actually solved this, but it went away. I went over the
execution path once more today (think fresh eyes might catch something
new). I realized that the Connection object was never closed or deleted.
I added a call to ->close() and a delete statement. Now the data
corruption is gone.
I am using the State Threads library, but the library never actually
creates a new thread (the exception was being thrown in the startup
code, before new threads are needed) so it is unlikely that this was
causing a problem. Any ideas how closing or not closing the Connection
object (well after the conversion is made) could have any effect on the
conversion? If anything, I would think that the data corruption would
happen if the conversion happened _after_ the connection was closed.
Drew Vogel
