Thank you Martin for your response. "囀湔祛堤" is not readable, no one knows
what it means. refno is a string type and $ord_num is also string type
contains number characters. e.g. "88090"
I just don't understand the same codes run on XP is ok but not on Windows
2003 server. the only thing I can think of is the permision issue. BUT
proper rights are given to the a/c runs the script.
Samuel
----- Original Message -----
From: "Martin Evans" <[EMAIL PROTECTED]>
To: "dbi-users" <dbi-users@perl.org>
Sent: Wednesday, August 15, 2007 8:26 AM
Subject: Re: DBI DBD-ODBC
Samuel_Zheng wrote:
I am having almost the same error on a windows 2003 server.
I don't see this as the same. Robert is having a connection problem and
you are having an execute problem.
Same set of scripts run fine on a Windows XP,
the following is the error:
DBD::ODBC::st execute failed: [Microsoft][ODBC Microsoft Access Driver]
囀湔祛堤 (SQL-22018)(DBD: st_execute/SQLExecute err=-1) at
c:\web\factory.pl line 61.
As I said when you posted this before - What does "囀湔祛堤" mean in
English? Error 22018 in access, is "Invalid character value for cast
specification" which is described for SQLExecute as:
"StatementText contained a C type that was an exact or approximate
numeric, a datetime, or an interval data type; the SQL type of the column
was a character data type; and the value in the column was not a valid
literal of the bound C type."
See
http://www.easysoft.com/developer/interfaces/odbc/sqlstate_status_return_codes.html#22018
I would be suspicious of the "wkmaster.refno like '$ord_num%'"" in your
code. What type is column refno, what is in $ord_num? What does an ODBC
trace contain?
it failed at the line to execute after prepared the sql.I wish someone
will shed some light on this. Thanks.I am using the format of
DBI->connect('dbi:ODBC:mydsn');I think. What is the difference?
The difference is that DBD::ODBC calls the newer ODBC connection API
SQLDriverConnect first then if this fails it attempts to use the older
ODBC API SQLConnect. If you are using a DSN then omitting DSN= will cause
SQLDriverConnect to attempt to connect using the DEFAULT data source which
for most people does not exist and hence fails. When SQLDriverConnect
fails DBD::ODBC will have a second attempt with the older ODBC API
SQLConnect.
I believe this is historical in that initially:
DBI->connect('dbi:ODBC:mydsn_name', 'uid', 'pwd')
(before ODBC 3) used to call SQLConnect and works fine so long as the DSN
mydsn_name exists but SQLConnect is less flexible than the newer
SQLDriverConnect which supports new ODBC attributes and driver-specific
attributes which are required for say DSN-less connections.
the sample code as following:my ($dbh, $sth);my $dsn =
"dbi:ODBC:btn";my $user ="";my $pswrd ="";my $driver = "ODBC";my
$wkno;use Time::gmtime;my
$ltime=localtime(time);open(LOG,">>chkorder.log");print LOG
"$ltime~~$ord_num~~\t$ENV{'REMOTE_ADDR'}\t$ENV{'HTTP_USER_AGENT'}\t$ENV{'REMOTE_HTTP_REFERER'}\n";close(LOG);$sql="Select
refno, workno,prdcode,prdDesc,duedate from wkMaster WHERE wkmaster.refno
like '$ord_num%'"; print $starter; $dbh =
DBI->connect($dsn,$user,$pswrd,$driver,{RaiseError=>1}) or die "Database
connection not made: $DBI::errstr"; $sth = $dbh->prepare($sql);
$sth->execute();It failed at the last line shown above. I highly
appreciate your help!Samuel
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
__________ NOD32 2463 (20070815) Information __________
This message was checked by NOD32 antivirus system.
http://www.nod32.com.hk