in reply to Quote mark in string messing up mySQL INSERT

Placeholders. Definately placeholders. You won't have to worry about quoting then because it happens automatically (or even for some cases it saves a step or two internally)

sub insertAttribute {
   my ($serverID, $featureID, $value) = @_;
   my $sqlINS = q{ INSERT INTO attribute VALUES (?, ?, ?) };

   $dbh->do ( $sqlINS,
              undef,
              $serverID,
              $featureID,
              $value );
}

[download]

Update: BTW I said exactly this yesterday Re^2: Strange experiences w/ perl 5.6.0 on linux 2.2.16-22

__SIG__
use B;
printf "You are here %08x\n", unpack "L!", unpack "P4", pack
  "L!", B::svref_2object(sub{})->OUTSIDE;

[download]

Replies are listed 'Best First'.
Re: Re: Quote mark in string messing up mySQL INSERT
by hmerrill (Friar) on Dec 12, 2002 at 13:53 UTC
    I second this - placeholders is definitely the way to go. Get used to using them - not only will you not have to worry about proper quoting any more, but in some situations you'll get big performance gains. There's really no reason not to use placeholders, and many reasons *to* use them.

    You may already by doing this, but since I can't see any in your submitted code, I'll just add that you should be error checking your DBI statements. I typically use "RaiseError" with "eval" - proper error checking is described very nicely in the DBI perldocs. 
        perldoc DBI

    [download]
    at a command prompt.

    HTH.
[reply]
[d/l]
Re^2: Quote mark in string messing up mySQL INSERT
by tadman (Prior) on Dec 12, 2002 at 15:18 UTC
    There's a problem with MySQL and placeholders which I discovered in Re^2: DBD::mysql Unusual Behavior. The only sure-fire way to work around it is to ensure that your string values are string values. In short, this means that the internal type of the variable is set correctly.

    If the first variable sent into the placeholder is an integer, subsequent calls using the same statement handle might fail on string data. Here, this is just a do() call, so you're probably okay. If you use prepare() and more than one execute() you can encounter problems. 
    sub insertAttribute
{
    my ($serverID, $featureID, $value) = @_;
    my $sqlINS = "INSERT INTO attribute VALUES (?,?,?)";

    $dbh->do($sqlINS, {},
              "$serverID",
              "$featureID",
              "$value");
}

    [download]
    Of course, this might depend on the version of DBD::mysql that you use.
[reply]
[d/l]
      Also, last I checked, you CANNOT use placeholders with the version of DBD::Sybase that works with FreeTDS and MS-SQL. :(
      --
      Spring: Forces, Coiled Again!
[reply]
        Or to be specific, FreeTDS hasn't yet implemented the API calls that are needed to handle placeholders at the protocol level.

        It should be noted that although Sybase and MS-SQL both "speak" the TDS protocol the two companies have diverged significantly in the last few years, and handling of placeholders is different with MS-SQL (TDS version 7 and 8) compared to Sybase (TDS version 5).

        Among other things Sybase has implemented a capability based negotiation functionality when the client and server first connect, which makes the protocol extensible without necessarily having to rev the protocol version. This is why DBD::Sybase calls ct_capability(CS_CAP_REQUEST, CS_REQ_DYN) to check if the server is capable of handling "dynamic" requests (i.e. placeholders). As this request doesn't exist in the MS version of the protocol the FreeTDS folks will have to emulate it (not too hard, probably).
        But it's implementing the rest of the functionality that is needed to handle this stuff in a manner consistent with the way DBD::Sybase expects it to work that I think could be tricky.

        I've been thinking for a while that it might be a good idea to create a DBD module that is more specific to FreeTDS and MS-SQL, instead of (or in addition to) trying to shoehorn DBD::Sybase into this function.

        Michael

[reply]

In Section Seekers of Perl Wisdom