Skip Menu |

This queue is for tickets about the DBD-ODBC CPAN distribution.

Report information
The Basics
Id: 46597
Status: resolved
Priority: 0/
Queue: DBD-ODBC

People
Owner: Nobody in particular
Requestors: msbb [...] ku.edu
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 1.21
Fixed in: 1.21_1



Subject: Problems with Access memo fields when using DBD::ODBC 1.21
Hello. Whenever I try to insert data in a memo field in an Access database, I get the error DBD::ODBC::st bind_param failed: Microsoft ODBC Microsoft Access Driver Invalid precision value (SQL-HY104) when I try to bind the variable using DBI::SQL_LONGVARCHAR. I am trying to bind it dynamically by using column_info to look up the field type, but even the simplified version of the code doesn't work (see attached). It used to before I upgraded DBD-ODBC to version 1.21 and DBI to 1.608. The string I am trying to insert is about 3000+ characters long. Any help is appreciated. Thanks and best wishes.
Subject: snnipet.txt
#!/usr/bin/perl -w use strict; use DBI; # Defines paths to databases my $dbpath = 'C:\\MyPath\\MyDB.mdb'; # Establish connection with databases my $sth = DBI->connect("dbi:ODBC:driver=Microsoft Access Driver (*.mdb, *.accdb); dbq=$dbpath ", {RaiseError => 1}) || print "Cannot connect to database.\n$DBI::errstr"; $sth->{LongReadLen} = 7000; # Data to be inserted my @data = ( "Locus", "Organism", "1", "3199", "GAAGCGGGATGAGCTCAAACTTAAAATCTCTGTTGCTTGCAACAGCGAATTGTAGTCTCGAGAAGCGTTTTCAAGGCGGATGCACAGTGCTCAAGTTGCTTGGAACGGCACATCGTAGAGGGTGACAATCCCGTACGTGGCACTGTGTACTGTTCACGATTCGCTTTCTATGAGTCGGGTTGCTTGGGAATGCAGCCCAAAATGGGAGGTAAACTCCTTCTAAAGCTAAATATTGGCACGAGACCGATAGCGAACAAGTACCGTGAGGGAAAGATGAAAAGCACTTTGAAAAGAAAGTTAATAGTACGTGAAACCGTTAGTAGGGAAGCGCATGGAATTAGCAATACACTGTCGAGATTCAGGCGGGCGGCGATTGGTACGGCTGTTGTACGGATCTGAATGGACCGTCGGTGGTCGTCACTGGTTGCTGCCTGTTGCATTTCCCGGCAGTGTTCGTCAACAGGTGTTGGAACCGAGCGATAAGCCCCGCAGGAAGGTGGCTGGCTTCGGCTAGTGTTATAGCCTGTGGTGTGCGAGCTCGGGTCCGACAGAGGGGTTGCGGCACATGCTCTTTTGGGCTGGTCTCGTCTCTCTCGGCTGGTTGTCGACTATGGCGGACTGCGTGCAGTGCGCTTGAACTGCTGCCGGTCGTCGAGGGGCATCGGACACACATTGTGCCAAGGTTGTTGGCGGTCATATGGTTTCATACGACCCGTCTTGAAACACGGACCAAGGAGTCTAACATGTGTGCGAGTCTTTGGGTGATCGAAACCCGCAGGCACAATGAAAGTAAAGGCTGCTTGCAGCTGAAGTGAGATCTCCCGGTCTCGGCCGGGGGCGCATCATTGACCGACCTATTCTACTCCTAGAAAGGTTTGAGTAAGAGCACATCTGTTGGGACCCGAAAGATGGTGAACTATGCTTGAGTAGGGCGAAGCCAGAGGAAACTCTGGTGGAGGCTCGTAGCGATTCTGACGTGCAAATCGATCGTCAAACTTGAGTATAGGGGCGAAAGACTAATCGAACCATCTAGTAGCTGGTTCCCTCCGAAGTTTCCCTTAGGATAGCTGGAACTCGGAACAGTTTTATCAGGTAAAGCGAATGATTAGAGGTCTTAGGATTGAAACAATCTTAACCTATTCTCAAACTTTAAATTGGTAAGAAGCCCGGCTTGCTTAACTGAAGCAGGGCACAGAATGAGAGTTCTTAGTGGGCCATTTTTGGTAAGCAGAACTGGCGATGCGGGATGAACCGAACGCTGAGTTAAGGCGTCTAAATCGACGCTCATCAGACCCCACAAAAGGTGTTGGTTGATCTAGACAGCAGGACGGTGGCCATGGAAGTCGGAATCCGCTAAGGAGTGTGTAACAACCCACCTGCCGAATCAACTAGCCCTGAAAATGGATGACGCTCAAGCGTCGTGCCTATACTCAGCCGTCAACGTAAATAGCGAAGCGTTGACGAGTAGGAGGGCGTGGGGATCGTGACGCAGCCTTTGGCGTGAGCCTGGGTGAAACGGTCTCTAGTGAAGATCTTGGTGGTAGTAGCAAATATTCAAATGAGAACTTTGAAGACCGAAGTGGAGAAAGGTTCCATGTGAACAGCAGTTGGACATGGGTTAGTCGATCCTAAGAGATAGGGAAACTCCGTTTCAAAGTGTCCGATCTTGGACCGTTTATCGAAAGGGAATCGGGTTAATATTCCCGAACCAGAACGCGGATATTCTAGCCTCTCGGGGTTAGATGTGCGGTAACGCAACTGAACTCGGAGACGTCGGCAGGGGCCCTGGGAAGAGTTCTCTTTTCTTGTTAACGACCTGACACCATGGAATCTGATTGCCAGGAGATATGGTTTGATGGTCGGTAAAGCACCACACTTCTTGTGGTGTCCGGTGCGCTCCTGAAGGCCCTTGAAAATCCGAGGGAAAGATTGATTTTCGCGTCTGTTCGTACTCATAACCGCAGCAGGTCTCCAAGGTGAGCAGCCTCTGGTCGATAGAACAATGTAGGTAAGGGAAGTCGGCAAAATAGATCCGTAACTTCGGGAAAAGGATTGGCTCTAAGGATTGGGTCTGTCGGGCTGAGACTTGAAGCGGGCGGCACCGACTCGGACTGGCTGTGGCCTCTCGGGGCTATGGTTGGACTGGGAAGGAACTGCGCGTGGATTGGCCCAGCTATGCTCGCAAGAGCAGTTCGGCAGGCAATTAACAATCAACTTAGAACTGGTACGGACAAGGGGAATCCGACTGTTTAATTAAAACAAAGCATTGCGATGGCCGGAAACGGTGTTGACGCAATGTGATTTCTGCCCAGTGCTCTGAATGTCAAAGTGAAGAAATTCAACCAAGCGCGGGTAAACGGCGGGAGTAACTATGACTCTCTTAAGGTAGCCAAATGCCTCGTCATCTAATTAGTGACGCGCATGAATGGATTAACGAGATTCCCACTGTCCCTATCTACTATCTAGCGAAACCACAGCCAAGGGAACGGGCTTGGCAAAATCAGCGGGGAAAGAAGACCCTGTTGAGCTTGACTCTAGTCTGACTCTGTGAAAAGACATAGGAGGTGTAGAATAGGTGGGAGCAGCAATGCAACAGTGAAATACCACTACTCTTATAGTTTTTTTACTTATTCGATTGAGCGGAAGCGAGCTTCACGGCTCATTTTCTAGAATTAAGGCCCCATTGGCGGGTCGATCCGTGTCGAAGACACTGTCAGGTTGGGAGTTTGGCTGGGGCGGCACATCTGTCAAATGATAACGCAGGTGTCCTAAGGTGAGCTCAATGAGAACGGAAATCTCATGTAGAACAAAAGGGTAAAAGCTCACTTGATTTTGATTTTCAGTATGAATACAAACTGTGAAAGCATGGCCTATCGATCCTTTAGTCTTTAGGAGTTTTAAGCTAGAGGTGTCAGAAAAGTTACCACAGGGATAACTGGCTTGTGGCAGCCAAGCGTTCATAGCGACGTTGCTTTTTGATCCTTCGATGTCGGCTCTTCCTATCATTGTGAAGCAGAATTCACCAAGTGTTGGATTGTTCACCCACTAATAGGGAACGTGAGCTGGGTTTAGACCGTCGTGAGACAGGTTAGTTTTACCCTACTGATGAAGTGTTGTTGCAATAGTAATTCTGCTCAGTACGAGAGGAACCGCAGATTCAGACAATTGGCATTTGCACTTGCTTGAAAAGGCAATGGTG"); # Bind line my $dbInsert = $sth->prepare("INSERT INTO Table VALUES ?, ?, ?, ?, ?", {RaiseError => 1}) || die ($DBI::errstr); $dbInsert->bind_param(1, $data[0], DBI::SQL_VARCHAR); $dbInsert->bind_param(2, $data[1], DBI::SQL_VARCHAR); $dbInsert->bind_param(3, $data[2], DBI::SQL_INTEGER); $dbInsert->bind_param(4, $data[3], DBI::SQL_INTEGER); $dbInsert->bind_param(5, $data[4], DBI::SQL_LONGVARCHAR); # Inserts and disconnect $dbInsert->execute(@data) || die "$DBI::errstr\n"; $dbInsert->finish; $sth->disconnect;
On Mon Jun 01 13:59:20 2009, taioba wrote: Show quoted text
> Hello. Whenever I try to insert data in a memo field in an Access > database, I get the error > > DBD::ODBC::st bind_param failed: Microsoft ODBC Microsoft Access Driver > Invalid precision value (SQL-HY104)
<snipped the rest> I will look into this tomorrow. In the mean time can you update your example to create the table in access then I'll have the same schema as you. Martin -- Martin J. Evans Wetherby, UK
Subject: RE: [rt.cpan.org #46597] Problems with Access memo fields when using DBD::ODBC 1.21
Date: Mon, 1 Jun 2009 18:00:28 -0500
To: <bug-DBD-ODBC [...] rt.cpan.org>
From: "Barbeitos, Marcos" <msbb [...] ku.edu>
There goes the snippet. Thanks! #!/usr/bin/perl -w use strict; use DBI; # Defines paths to databases my $dbpath = 'C:\\MyPath\\MyDB.mdb'; # Establish connection with databases my $sth = DBI->connect("dbi:ODBC:driver=Microsoft Access Driver (*.mdb, *.accdb); dbq=$dbpath ", {RaiseError => 1}) || print "Cannot connect to database.\n$DBI::errstr"; $sth->{LongReadLen} = 7000; # Create table my $createString = "CREATE TABLE TestTable (Accession text, Taxon text, Begins number, Ends number, Sequence memo)"; my $dbCreate = $sth->prepare($createString) or die "$DBI::errstr"; $dbCreate->execute || die "$DBI::errstr\n"; # Data to be inserted my @data = ( "Locus", "Organism", "1", "3199", "GAAGCGGGATGAGCTCAAACTTAAAATCTCTGTTGCTTGCAACAGCGAATTGTAGTCTCGAGAAGCGTTTTCAAGGCGGATGCACAGTGCTCAAGTTGCTTGGAACGGCACATCGTAGAGGGTGACAATCCCGTACGTGGCACTGTGTACTGTTCACGATTCGCTTTCTATGAGTCGGGTTGCTTGGGAATGCAGCCCAAAATGGGAGGTAAACTCCTTCTAAAGCTAAATATTGGCACGAGACCGATAGCGAACAAGTACCGTGAGGGAAAGATGAAAAGCACTTTGAAAAGAAAGTTAATAGTACGTGAAACCGTTAGTAGGGAAGCGCATGGAATTAGCAATACACTGTCGAGATTCAGGCGGGCGGCGATTGGTACGGCTGTTGTACGGATCTGAATGGACCGTCGGTGGTCGTCACTGGTTGCTGCCTGTTGCATTTCCCGGCAGTGTTCGTCAACAGGTGTTGGAACCGAGCGATAAGCCCCGCAGGAAGGTGGCTGGCTTCGGCTAGTGTTATAGCCTGTGGTGTGCGAGCTCGGGTCCGACAGAGGGGTTGCGGCACATGCTCTTTTGGGCTGGTCTCGTCTCTCTCGGCTGGTTGTCGACTATGGCGGACTGCGTGCAGTGCGCTTGAACTGCTGCCGGTCGTCGAGGGGCATCGGACACACATTGTGCCAAGGTTGTTGGCGGTCATATGGTTTCATACGACCCGTCTTGAAACACGGACCAAGGAGTCTAACATGTGTGCGAGTCTTTGGGTGATCGAAACCCGCAGGCACAATGAAAGTAAAGGCTGCTTGCAGCTGAAGTGAGATCTCCCGGTCTCGGCCGGGGGCGCATCATTGACCGACCTATTCTACTCCTAGAAAGGTTTGAGTAAGAGCACATCTGTTGGGACCCGAAAGATGGTGAACTATGCTTGAGTAGGGCGAAGCCAGAGGAAACTCTGGTGGAGGCTCGTAGCGATTCTGACGTGCAAATCGATCGTCAAACTTGAGTATAGGGGCGAAAGACTAATCGAACCATCTAGTAGCTGGTTCCCTCCGAAGTTTCCCTTAGGATAGCTGGAACTCGGAACAGTTTTATCAGGTAAAGCGAATGATTAGAGGTCTTAGGATTGAAACAATCTTAACCTATTCTCAAACTTTAAATTGGTAAGAAGCCCGGCTTGCTTAACTGAAGCAGGGCACAGAATGAGAGTTCTTAGTGGGCCATTTTTGGTAAGCAGAACTGGCGATGCGGGATGAACCGAACGCTGAGTTAAGGCGTCTAAATCGACGCTCATCAGACCCCACAAAAGGTGTTGGTTGATCTAGACAGCAGGACGGTGGCCATGGAAGTCGGAATCCGCTAAGGAGTGTGTAACAACCCACCTGCCGAATCAACTAGCCCTGAAAATGGATGACGCTCAAGCGTCGTGCCTATACTCAGCCGTCAACGTAAATAGCGAAGCGTTGACGAGTAGGAGGGCGTGGGGATCGTGACGCAGCCTTTGGCGTGAGCCTGGGTGAAACGGTCTCTAGTGAAGATCTTGGTGGTAGTAGCAAATATTCAAATGAGAACTTTGAAGACCGAAGTGGAGAAAGGTTCCATGTGAACAGCAGTTGGACATGGGTTAGTCGATCCTAAGAGATAGGGAAACTCCGTTTCAAAGTGTCCGATCTTGGACCGTTTATCGAAAGGGAATCGGGTTAATATTCCCGAACCAGAACGCGGATATTCTAGCCTCTCGGGGTTAGATGTGCGGTAACGCAACTGAACTCGGAGACGTCGGCAGGGGCCCTGGGAAGAGTTCTCTTTTCTTGTTAACGACCTGACACCATGGAATCTGATTGCCAGGAGATATGGTTTGATGGTCGGTAAAGCACCACACTTCTTGTGGTGTCCGGTGCGCTCCTGAAGGCCCTTGAAAATCCGAGGGAAAGATTGATTTTCGCGTCTGTTCGTACTCATAACCGCAGCAGGTCTCCAAGGTGAGCAGCCTCTGGTCGATAGAACAATGTAGGTAAGGGAAGTCGGCAAAATAGATCCGTAACTTCGGGAAAAGGATTGGCTCTAAGGATTGGGTCTGTCGGGCTGAGACTTGAAGCGGGCGGCACCGACTCGGACTGGCTGTGGCCTCTCGGGGCTATGGTTGGACTGGGAAGGAACTGCGCGTGGATTGGCCCAGCTATGCTCGCAAGAGCAGTTCGGCAGGCAATTAACAATCAACTTAGAACTGGTACGGACAAGGGGAATCCGACTGTTTAATTAAAACAAAGCATTGCGATGGCCGGAAACGGTGTTGACGCAATGTGATTTCTGCCCAGTGCTCTGAATGTCAAAGTGAAGAAATTCAACCAAGCGCGGGTAAACGGCGGGAGTAACTATGACTCTCTTAAGGTAGCCAAATGCCTCGTCATCTAATTAGTGACGCGCATGAATGGATTAACGAGATTCCCACTGTCCCTATCTACTATCTAGCGAAACCACAGCCAAGGGAACGGGCTTGGCAAAATCAGCGGGGAAAGAAGACCCTGTTGAGCTTGACTCTAGTCTGACTCTGTGAAAAGACATAGGAGGTGTAGAATAGGTGGGAGCAGCAATGCAACAGTGAAATACCACTACTCTTATAGTTTTTTTACTTATTCGATTGAGCGGAAGCGAGCTTCACGGCTCATTTTCTAGAATTAAGGCCCCATTGGCGGGTCGATCCGTGTCGAAGACACTGTCAGGTTGGGAGTTTGGCTGGGGCGGCACATCTGTCAAATGATAACGCAGGTGTCCTAAGGTGAGCTCAATGAGAACGGAAATCTCATGTAGAACAAAAGGGTAAAAGCTCACTTGATTTTGATTTTCAGTATGAATACAAACTGTGAAAGCATGGCCTATCGATCCTTTAGTCTTTAGGAGTTTTAAGCTAGAGGTGTCAGAAAAGTTACCACAGGGATAACTGGCTTGTGGCAGCCAAGCGTTCATAGCGACGTTGCTTTTTGATCCTTCGATGTCGGCTCTTCCTATCATTGTGAAGCAGAATTCACCAAGTGTTGGATTGTTCACCCACTAATAGGGAACGTGAGCTGGGTTTAGACCGTCGTGAGACAGGTTAGTTTTACCCTACTGATGAAGTGTTGTTGCAATAGTAATTCTGCTCAGTACGAGAGGAACCGCAGATTCAGACAATTGGCATTTGCACTTGCTTGAAAAGGCAATGGTG"); # Bind line my $dbInsert = $sth->prepare("INSERT INTO TestTable VALUES ?, ?, ?, ?, ?", {RaiseError => 1}) || die ($DBI::errstr); $dbInsert->bind_param(1, $data[0], DBI::SQL_VARCHAR); $dbInsert->bind_param(2, $data[1], DBI::SQL_VARCHAR); $dbInsert->bind_param(3, $data[2], DBI::SQL_INTEGER); $dbInsert->bind_param(4, $data[3], DBI::SQL_INTEGER); $dbInsert->bind_param(5, $data[4], DBI::SQL_LONGVARCHAR); # Inserts and disconnect $dbInsert->execute(@data) || die "$DBI::errstr\n"; $dbInsert->finish; $sth->disconnect; Show quoted text
-----Original Message----- From: Martin J Evans via RT [mailto:bug-DBD-ODBC@rt.cpan.org] Sent: Mon 6/1/2009 2:48 PM To: Barbeitos, Marcos Subject: [rt.cpan.org #46597] Problems with Access memo fields when using DBD::ODBC 1.21 <URL: https://rt.cpan.org/Ticket/Display.html?id=46597 > On Mon Jun 01 13:59:20 2009, taioba wrote:
> Hello. Whenever I try to insert data in a memo field in an Access > database, I get the error > > DBD::ODBC::st bind_param failed: Microsoft ODBC Microsoft Access Driver > Invalid precision value (SQL-HY104)
<snipped the rest> I will look into this tomorrow. In the mean time can you update your example to create the table in access then I'll have the same schema as you. Martin -- Martin J. Evans Wetherby, UK
Download winmail.dat
application/ms-tnef 5.2k

Message body not shown because it is not plain text.

On Mon Jun 01 19:03:35 2009, taioba wrote: Show quoted text
> There goes the snippet. Thanks!
Thanks. I have reproduced this now. Hope to get back to you soon. Martin -- Martin J. Evans Wetherby, UK
On Tue Jun 02 03:45:05 2009, MJEVANS wrote: Show quoted text
> On Mon Jun 01 19:03:35 2009, taioba wrote:
> > There goes the snippet. Thanks!
You should decide if you are binding the parameters yourself or letting DBD::ODBC do it for you. That is you are binding the parameters with types then passing them all to the execute method. When you do this, DBD::ODBC has to rebind the parameters itself and because MS Access does not support SQLDescribeParam it cannot know the fifth parameter is a memo so binds it using SQL_VARCHAR (which does not work). If you change your code to avoid passing @data to execute it should work as you need to bind memo fields as SQL_LONGVARCHARs (which you have done). If, once you've removed the @data from the execute call it still does not work let me know. If you think the code you sent used to work with an earlier DBD::ODBC please let me know which version of DBD::ODBC that was. Either way, get back to me so I can work out what to do with this rt. Martin -- Martin J. Evans Wetherby, UK
Subject: Re: [rt.cpan.org #46597] Problems with Access memo fields when using DBD::ODBC 1.21
Date: Tue, 2 Jun 2009 10:38:04 +0100
To: Martin J Evans via RT <bug-DBD-ODBC [...] rt.cpan.org>
From: Tim Bunce <Tim.Bunce [...] pobox.com>
On Tue, Jun 02, 2009 at 04:50:38AM -0400, Martin J Evans via RT wrote: Show quoted text
> Queue: DBD-ODBC > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=46597 > > > You should decide if you are binding the parameters yourself or letting > DBD::ODBC do it for you. That is you are binding the parameters with > types then passing them all to the execute method. When you do this, > DBD::ODBC has to rebind the parameters itself and because MS Access does > not support SQLDescribeParam it cannot know the fifth parameter is a > memo so binds it using SQL_VARCHAR (which does not work).
That seems like a bug in DBD::ODBC. Bind types are meant to be 'sticky'. "The data type for a placeholder cannot be changed after the first bind_param call. In fact the whole \%attr parameter is 'sticky' in the sense that a driver only needs to consider the \%attr parameter for the first call, for a given $sth and parameter. After that the driver may ignore the \%attr parameter for that placeholder." (That's not well worded and probably not strictly correct in all cases. The 2nd and 3rd mentions of \%attr should probably be 'data type'.) Also the docs for execute() say: "If any arguments are given, then C<execute> will effectively call L</bind_param> for each value before executing the statement. Values bound in this way are usually treated as C<SQL_VARCHAR> types unless the driver can determine the correct type (which is rare), or unless C<bind_param> (or C<bind_param_inout>) has already been used to specify the type." Tim.
On Tue Jun 02 05:38:32 2009, Tim.Bunce@pobox.com wrote: Show quoted text
> On Tue, Jun 02, 2009 at 04:50:38AM -0400, Martin J Evans via RT wrote:
> > Queue: DBD-ODBC > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=46597 > > > > > You should decide if you are binding the parameters yourself or letting > > DBD::ODBC do it for you. That is you are binding the parameters with > > types then passing them all to the execute method. When you do this, > > DBD::ODBC has to rebind the parameters itself and because MS Access does > > not support SQLDescribeParam it cannot know the fifth parameter is a > > memo so binds it using SQL_VARCHAR (which does not work).
> > That seems like a bug in DBD::ODBC. Bind types are meant to be 'sticky'. > > "The data type for a placeholder cannot be changed after the first > bind_param call. In fact the whole \%attr parameter is 'sticky' in the > sense that a driver only needs to consider the \%attr parameter
for the Show quoted text
> first call, for a given $sth and parameter. After that the driver may > ignore the \%attr parameter for that placeholder." > > (That's not well worded and probably not strictly correct in all cases. > The 2nd and 3rd mentions of \%attr should probably be 'data type'.) > > Also the docs for execute() say: > > "If any arguments are given, then C<execute> will effectively call > L</bind_param> for each value before executing the statement. Values > bound in this way are usually treated as C<SQL_VARCHAR> types unless > the driver can determine the correct type (which is rare), or unless > C<bind_param> (or C<bind_param_inout>) has already been used to > specify the type." > > Tim.
Thanks for that Tim (and I notice you've already updated DBI pod). DBD::ODBC was saving the requested type when the parameter was first bound but then changing the requested type to a default type when execute was called with the same parameter values. I have fixed that but I would find it difficult to comply with the DBI pod as it stands now and for DBD::ODBC it would be restrictive (even breaking some existing code). DBD::ODBC will now save the requested bind type and continue to use it in further executes of the same statement UNTIL you specifically bind it again (if you do that you can specify a different type). In fact DBD::ODBC goes out of its way to allow this by rebinding the parameter. This behavior coincides with ODBC which allows you to rebind a parameters differently as much as you like. As far as I am concerned, to prevent rebinding would a) be a backwards step for DBD::ODBC b) break existing code and I have no wish to do either of those. Unless you can come with a compelling reason I have not thought of to fully comply with this restriction in DBI I will document it in DBD::ODBC under http://search.cpan.org/~mjevans/DBD-ODBC-1.21/ODBC.pm#Deviations_from_the_DBI_specification. Martin -- Martin J. Evans Wetherby, UK
Subject: Re: [rt.cpan.org #46597] Problems with Access memo fields when using DBD::ODBC 1.21
Date: Tue, 2 Jun 2009 16:13:35 +0100
To: Martin J Evans via RT <bug-DBD-ODBC [...] rt.cpan.org>
From: Tim Bunce <Tim.Bunce [...] pobox.com>
On Tue, Jun 02, 2009 at 08:37:11AM -0400, Martin J Evans via RT wrote: Show quoted text
> > Thanks for that Tim (and I notice you've already updated DBI pod). > DBD::ODBC was saving the requested type when the parameter was first > bound but then changing the requested type to a default type when > execute was called with the same parameter values. I have fixed that but > I would find it difficult to comply with the DBI pod as it stands now > and for DBD::ODBC it would be restrictive (even breaking some existing > code).
I've changed it to a better wording: -The data type for a placeholder cannot be changed after the first C<bind_param> -call. The data type is said to be 'sticky'. Bind values passed to execute() -are bound with the data type specified by earlier bind_param() calls, if any. +The data type is 'sticky' in that bind values passed to execute() are bound +with the data type specified by earlier bind_param() calls, if any. +Portable applications should not rely on being able to change the data type +after the first C<bind_param> call. Tim.
On Tue Jun 02 11:14:03 2009, Tim.Bunce@pobox.com wrote: Show quoted text
> On Tue, Jun 02, 2009 at 08:37:11AM -0400, Martin J Evans via RT wrote:
> > > > Thanks for that Tim (and I notice you've already updated DBI pod). > > DBD::ODBC was saving the requested type when the parameter was first > > bound but then changing the requested type to a default type when > > execute was called with the same parameter values. I have fixed that
> but
> > I would find it difficult to comply with the DBI pod as it stands
> now
> > and for DBD::ODBC it would be restrictive (even breaking some
> existing
> > code).
> > I've changed it to a better wording: > > -The data type for a placeholder cannot be changed after the first > C<bind_param> > -call. The data type is said to be 'sticky'. Bind values passed to > execute() > -are bound with the data type specified by earlier bind_param() calls, > if any. > > +The data type is 'sticky' in that bind values passed to execute() are > bound > +with the data type specified by earlier bind_param() calls, if any. > +Portable applications should not rely on being able to change the > data type > +after the first C<bind_param> call. > > Tim.
Thanks - that is "most acceptable" :-) Martin -- Martin J. Evans Wetherby, UK
On Mon Jun 01 19:03:35 2009, taioba wrote: Show quoted text
> There goes the snippet. Thanks! >
I now have a version of DBD::ODBC that works with your original code. Of course, if you modify your original code to not pass @data on the execute call you existing DBD::ODBC will work. If you would like a copy of the new DBD::ODBC (tar file - you would have to build it for Windows) let me know privately at mjevans@cpan.org with details of where you would like it mailed and I will sort this out. Martin -- Martin J. Evans Wetherby, UK
Subject: RE: [rt.cpan.org #46597] Problems with Access memo fields when using DBD::ODBC 1.21
Date: Tue, 2 Jun 2009 10:37:45 -0500
To: <bug-DBD-ODBC [...] rt.cpan.org>
From: "Marcos S. Barbeitos" <msbb [...] ku.edu>
Excellent, thank you so much! I'll get to that in a minute and I'll let you know. Best wishes. Show quoted text
-----Original Message----- From: Martin J Evans via RT [mailto:bug-DBD-ODBC@rt.cpan.org] Sent: Tuesday, June 02, 2009 10:36 AM To: msbb@ku.edu Subject: [rt.cpan.org #46597] Problems with Access memo fields when using DBD::ODBC 1.21 <URL: https://rt.cpan.org/Ticket/Display.html?id=46597 > On Mon Jun 01 19:03:35 2009, taioba wrote:
> There goes the snippet. Thanks! >
I now have a version of DBD::ODBC that works with your original code. Of course, if you modify your original code to not pass @data on the execute call you existing DBD::ODBC will work. If you would like a copy of the new DBD::ODBC (tar file - you would have to build it for Windows) let me know privately at mjevans@cpan.org with details of where you would like it mailed and I will sort this out. Martin -- Martin J. Evans Wetherby, UK
Subject: RE: [rt.cpan.org #46597] Problems with Access memo fields when using DBD::ODBC 1.21
Date: Tue, 2 Jun 2009 11:23:52 -0500
To: <bug-DBD-ODBC [...] rt.cpan.org>
From: "Barbeitos, Marcos" <msbb [...] ku.edu>
Yep, not passing @data to execute command did the trick! This has been driving me crazy for a while now, glad that the solution was this simple. Best wishes and thanks again for your help. Show quoted text
-----Original Message----- From: Martin J Evans via RT [mailto:bug-DBD-ODBC@rt.cpan.org] Sent: Tue 6/2/2009 10:36 AM To: Barbeitos, Marcos Subject: [rt.cpan.org #46597] Problems with Access memo fields when using DBD::ODBC 1.21 <URL: https://rt.cpan.org/Ticket/Display.html?id=46597 > On Mon Jun 01 19:03:35 2009, taioba wrote:
> There goes the snippet. Thanks! >
I now have a version of DBD::ODBC that works with your original code. Of course, if you modify your original code to not pass @data on the execute call you existing DBD::ODBC will work. If you would like a copy of the new DBD::ODBC (tar file - you would have to build it for Windows) let me know privately at mjevans@cpan.org with details of where you would like it mailed and I will sort this out. Martin -- Martin J. Evans Wetherby, UK
Download winmail.dat
application/ms-tnef 3.4k

Message body not shown because it is not plain text.

Subject: RE: [rt.cpan.org #46597] Problems with Access memo fields when using DBD::ODBC 1.21
Date: Tue, 2 Jun 2009 14:48:03 -0500
To: <bug-DBD-ODBC [...] rt.cpan.org>
From: "Barbeitos, Marcos" <msbb [...] ku.edu>
So that you know, there's another issue that you should probably be aware of. If I use the string DBI::SQL_LONGVARCHAR to bind the parameter, it works just fine, but if I try to use a scalar with this value, DBD::ODBC returns an error message. Interesting enough, this happens only with DBI::SQL_LONGVARCHAR, all other types can be passed as variables without a problem. This is an issue if you're trying to bind your parameters dynamically. I got a sub-routine that uploads data to a bunch of different tables, so i have to bind the parameters using scalars. Show quoted text
-----Original Message----- From: Martin J Evans via RT [mailto:bug-DBD-ODBC@rt.cpan.org] Sent: Tue 6/2/2009 10:36 AM To: Barbeitos, Marcos Subject: [rt.cpan.org #46597] Problems with Access memo fields when using DBD::ODBC 1.21 <URL: https://rt.cpan.org/Ticket/Display.html?id=46597 > On Mon Jun 01 19:03:35 2009, taioba wrote:
> There goes the snippet. Thanks! >
I now have a version of DBD::ODBC that works with your original code. Of course, if you modify your original code to not pass @data on the execute call you existing DBD::ODBC will work. If you would like a copy of the new DBD::ODBC (tar file - you would have to build it for Windows) let me know privately at mjevans@cpan.org with details of where you would like it mailed and I will sort this out. Martin -- Martin J. Evans Wetherby, UK
Download winmail.dat
application/ms-tnef 3.7k

Message body not shown because it is not plain text.

On Tue Jun 02 12:48:23 2009, taioba wrote: Show quoted text
> So that you know, there's another issue that you should probably be > aware of. If I use the string DBI::SQL_LONGVARCHAR to bind the > parameter, it works just fine, but if I try to use a scalar with > this value, DBD::ODBC returns an error message. Interesting > enough, this happens only with DBI::SQL_LONGVARCHAR, all other > types can be passed as variables without a problem. This is an > issue if you're trying to bind your parameters dynamically. I got a > sub-routine that uploads data to a bunch of different tables, so i > have to bind the parameters using scalars. >
So I can write this report off as solved but you've found another issue. Could you send me privately mjevans@cpan.org an example of the problem you are describing and the error output. Did you look at: http://search.cpan.org/~mjevans/DBD-ODBC-1.21/FAQ#I'm_attempting_to_bind_a_Long_Var_char_(or_other_specific_type)_and_the_binding_is_not_working. Martin -- Martin J. Evans Wetherby, UK