>> If it's an STL container of SSQLSes instead, the only reason you might have had
to do that is that your SSQLS wasn't defined using mysqlpp::Null<T> wrappers on the
columns that can contain SQL NULL. That wasn't possible pre-MySQL++ 3.0, but it is now, so
any reason you had for doing that once has gone away.
That is good to know. I know that mysql++ has definitely had come code
changes. Every once in a while I find myself fixing some function in my program
because I'm using the "old" call to do things.
>> Getting back to Eric's issue, you are correct, Raymond, that comparing to the C
> NULL constant is wrong, and that part of the fix is to compare against MySQL++'s
> mysqlpp::null value.
I figured that was right. I remember using it somewhere in my code at one time
before I killed the use of NULL completely. That was part of my comparing sqltypes
to sqltypes learning curve back in the day. Most of my conversions for strings, etc
are done via ostringstream variable; variable << Result[x][y];... From that
placepoint I could use it how I wish. Then I simply create the execute statement
using the ostringstream variable which can be converted to string and then ultimately to
char (where needed). It's a painful process and but it allows me to include any
variable type in the execution line since using << dumps the contents of the
variable into ostringstream regardless of the type. This practice solves so many
issues and prevents having to cast everything into a string for execution which generally
leads to cast problems in the end anyhow.
I'm pretty sure I'm over-doing it these days, but it's how I learned to use mysql++ back
when it was in it's infancy. I never really updated my style since I've only looked
up things related to mysql++ when I end in a compile error for some member that is no
longer found in the new release of mysql++. In some of my examples I just simply
install the old version simply because the program is so big that making all the member
conversions and ensuring the program produces the same results can be painful in itself.
>>> I even use
>>> mysqlpp::sql_int_unsigned, etc for some of my variables
>>Are you using mysqlpp::sql_int_unsigned_null, etc., too? That's shorthand
> for mysqlpp::Null<sql_int_unsigned>, etc.
No, actually after the big issues with null long ago, I have completely eliminated NULL
from the equation of my programs with the "NOT NULL" column property. After that, I
never looked back at it until this e-mail showed up. As I stated before, I have zero
reason to ever use NULL... I can't think of one example that NULL would be better
than a zero byte string.
I think NULL should be able to be disabled via a flag during the init of the mysql++
library using a parm on the connect command. In that instance string should be
converted to "" and int to 0, etc... Basically the clients version of the "NOT NULL"
column property. But since I haven't found an option like that, I just handle it
from the SQL Server side. It's more suited for it anyway, you can set a default
value for the column which is something I'd never expect the client to keep track of.
Although it would be nice if the client looked up that information so I don't have to
execute the insert command and then relook it up using "SELECT" to actually get the
default values back (for instances where you are using struct to create inserts instead of
manual commands). Which isn't something I have to do that often but I've had
instances where I wanted to store the record number (index) from the table and since I
don't set that on INSERT and it's the primary key for the table, it creates it
automatically. The only way to get that key is to SELECT after the INSERT (Good for
those inserts where the key is something useful that needs to be reported back to the
user. IE: Maybe it's the Service Ticket #, etc which explains why it needs to
be unique). You could sort by Key and use the next key in line but in a networking
environment where more than one user is INSERTing a Service Ticket there is the
possibility of having a failure because two
clients tried to insert the same ticket number at the same time (one will likely succeed
and one will fail). For that instance alone it's better to let MySQL Server keep
track of the Key Column by incrementing it on it's own accord.