Daniel, According to SQLGetTypeInfo SQL Server type money is a SQL_DECIMAL. When DBD::ODBC sees a SQL_DECIMAL is binds it as a SQL_VARCHAR - there is no quoting involved because you are using bound parameters.
A quick test with isql from unixODBC showed: SQL> create table mjemny (a integer, b money) SQLRowCount returns 0 SQL> insert into mjemny values (1, 1) SQLRowCount returns 1 SQL> insert into mjemny values (1, '23') [37000][unixODBC][Microsoft][ODBC SQL Server Driver][SQL Server]Statement(s) could not be prepared. [37000][unixODBC][Microsoft][ODBC SQL Server Driver][SQL Server]Disallowed implicit conversion from data type varchar to data type money, table 'test.dbo.mjemny', column 'b'. Use the CONVERT function to run this query. [ISQL]ERROR: Could not SQLExecute which reproduces your problem I think (and is probably what you are referring to when you found this happens when using quotes). Using a convert would be your easiest solution (or change the column type). Other than that, DBD::ODBC would have to bind it as a SQL_C_FLOAT or SQL_C_DOUBLE (which would not be exact and therefore no good for a money column) or a SQL_C_NUMERIC with a scale of 4 (since that's what sql server says money has). Martin -- Martin J. Evans Easysoft Ltd, UK Development On 12-Jul-2005 Daniel Kasak wrote: > Hi all. > > I'm using the process: > > my $sth = $dbh->prepare ( "update xxx set a=?, b=?, c=? where d=?" ); > $sth->execute( $a, $b, $c, $d ); > > to update data in a SQL Server database. It works fine most of the time, > but if I have a 'money' column type in SQL Server, I get the following > error: > > [unixODBC][FreeTDS][SQL Server]Disallowed implicit conversion from data > type varchar to data type money, table 'NUSsql.dbo.EAPosting', column > 'EAPTotal'. Use the CONVERT function to run this query. (SQL-) > > I've googled around and found that this error occurs if you enclose a > money value in single quotes. There are a couple of problems with this. > > Firstly, I'm not quoting the values ... I assume something further up > the chain is. Possibly DBD::ODBC or FreeTDS? > Secondly, I've got a couple of layers of abstraction between getting the > data, processing it, and updating the database, and I really can't ( > without some *major* work ) insert convert() functions around things - > particularly since a lot of the stuff I'm doing is supposed to be > db-neutral. > > I suppose I can convert the data in SQL Server to something else. I > didn't set the table up - I wouldn't have used 'money' anyway, but I'm > not sure what effect changing it now will have. > > Anyone encountered this before? Looks like a bug to me. > > -- > Daniel Kasak > IT Developer > NUS Consulting Group > Level 5, 77 Pacific Highway > North Sydney, NSW, Australia 2060 > T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 > email: [EMAIL PROTECTED] > website: http://www.nusconsulting.com.au
