Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I just scanned thru the documentation [sqlite.org] for column types.

    First, this looks like it may be affecting you.

    A column with NUMERIC affinity may contain values using all five storage classes. When text data is inserted into a NUMERIC column, an attempt is made to convert it to an integer or real number before it is stored.

    Then, a few more lines down...

    2.1 Determination Of Column Affinity
     
    ...
     
       4. Otherwise, the affinity is NUMERIC.

    So, I'm wondering if the column type is defaulting

  • I've had the same problem. Although the field was of type TEXT, when I wanted to insert international phone number-style data (like '+4369912345678'), the '+' got cut off.

    The solution was to bind the data, not with SQL_VARCHAR, but with SQL_BLOB:

    $sth->bind_param(3, $data, SQL_BLOB);
  • I had a similar experience, and it turned out that use of bind_param and bind_col is the only solution, as a previous reply suggested. I found Perl was also part of the blame -- if a string can be treated as a number, DBI did indeed insert it as a number. Unfortunately, SQLite3 does the same thing. That "type affinity" thing is only for reference use only. In theory, if you say in the table schema that you want a column to be text, and indeed you insert the column and retrieve it as text, then 0, 01, 0.1 sh