Re: Invalid Precision error
On Mon, 30 Dec 2002 00:12:40 -0500, Jeff Thies wrote: I'm getting a weird error when I try to update a text field (Access, latest ODBC and DBI) sometimes: This is a placeholder problem. Changing the script so the affected field is not a placeholder eliminates the problem. ie: set text_field=? fails *sometimes* while set text_field='$text_field' does not. Where might the problem be? In that case, it sounds like an incorrect guess of the type of variable. Try something like use DBI ':sql_types'; # to import the constants ... $sth = $dbh-prepare($sql); $sth-bind_param(1, undef, SQL_VARCHAR); $sth-execute($value); i.e. inserting an appropriate bind_param call between the prepare and the execute. where you may try one of several constants instead of the SQL_VARCHAR. See the section on DBI Constants in the DBI docs. -- Bart.
Re: Oracle 8i and DBD 1.0X performance.
On Thu, Dec 26, 2002 at 11:13:54AM -0500, Eric Robinson wrote: Hi all, When using Oracle 8i and DBD 1.0X we see very poor performance when accessing data across the WAN. It appears from our testing that it does single row fetches to retrieve the data. Setting RowCacheSize and RowsInCache does not affect the performance. When you use Oracle 7.x and DBD 1.06 the performance is very good and it will fetch multiple rows when RowCacheSize and RowsInCache are set. Has anyone seen this before and is a fix available? See the archives. Make sure you're using the latest DBD::Oracle version (1.12). That may well help. Tim.
RE: Hate to bother you, but if you have the time, please take a look (DBD::ODBC)
Forwarded to dbi-users mailing list.
Hello,
Like I said in the subject, I really do hate to bother you
directly with
this, but I thought if anyone could help me with this, it
would probably be
you. I'm trying to use perl and DBD::ODBC to access stored
procs in a
remote database as part of a high-profile project within my
company - I am
sort of a 'lone ranger' type as there are not too many other
perl and open
source proponents at my level of responsibility at work so
I'm starting to
get a little twitchy about solving this particular problem.
Anyway, I hope
you'll forgive me, I know if everyone emailed the developer
with there
problems we'd probably be short on developers, but I have
tried many other
avenues and I'm still coming up short. My issue is that while I can
execute stored procs, I can;t get any return values in my
script, although
some data shows up in the driver trace. Also, just so you
knowm I did post
this to the dbi-users list a couple days ago. I'll copy
anything I learn
back to the list. I'm just not sure how much help I'll get
there as I
commited yet another faux pas - I somehow posted my message 3
times in a
row - my bad again. I also posted it to the freetds list and haven't
gotten anything on that front either.
Sincerely,
Chris McDaniel
BTW I'm using DBD::ODBC (0.45), MS SQL, unixODBC, and FreeTDS
(from CVS,
about a week old now)
I've also tried DBD::ODBC 0.43 and 1.01.
Thanks
Here is my code:
#!/usr/bin/perl -w
use DBI();
#connect to DB
my $dbh = DBI-connect(DBI:ODBC:SBS,
xx, xx,
{'RaiseError' = 1});
DBI-trace(2);
my ( $bind_value );
my $sth0 = $dbh-prepare('use BSRes2');
$sth0-execute();
$sth0-finish();
my $sth = $dbh-prepare('{?=call ShowConference 17050}');
$sth-bind_param_inout(1, \$bind_value, 1); $sth-execute();
print bv ,$bind_value,\n;
$sth-finish();
# close DB connection
$dbh-disconnect();
here is my output:
DBI 1.30-nothread dispatch trace level set to 2
- prepare for DBD::ODBC::db (DBI::db=HASH(0x1e8238)~0x1e8160 'use
BSRes2')
- prepare= DBI::st=HASH(0x1e8250) at test3.pl line 9
- execute for DBD::ODBC::st (DBI::st=HASH(0x1e8250)~0xf087c)
- execute= '0E0' at test3.pl line 10
- finish for DBD::ODBC::st (DBI::st=HASH(0x1e8250)~0xf087c)
- finish= 1 at test3.pl line 11
- prepare for DBD::ODBC::db
(DBI::db=HASH(0x1e8238)~0x1e8160 '{?=call
ShowConference 17050}')
- prepare= DBI::st=HASH(0x1e834c) at test3.pl line 12
- bind_param_inout for DBD::ODBC::st
(DBI::st=HASH(0x1e834c)~0x1884e0 1
SCALAR(0x1dc834) 1)
- bind_param_inout= 1 at test3.pl line 13
- execute for DBD::ODBC::st (DBI::st=HASH(0x1e834c)~0x1884e0)
- execute= '0E0' at test3.pl line 14
bv
- finish for DBD::ODBC::st (DBI::st=HASH(0x1e834c)~0x1884e0)
- finish= 1 at test3.pl line 18
- disconnect for DBD::ODBC::db (DBI::db=HASH(0x1e8238)~0x1e8160)
- disconnect= 1 at test3.pl line 20
- DESTROY for DBD::ODBC::st (DBI::st=HASH(0xf087c)~INNER)
- DESTROY= undef
- DESTROY for DBD::ODBC::st (DBI::st=HASH(0x1884e0)~INNER)
- DESTROY= undef
- DESTROY for DBD::ODBC::db (DBI::db=HASH(0x1e8160)~INNER)
- DESTROY= undef
-- DBI::END
- disconnect_all for DBD::ODBC::dr
(DBI::dr=HASH(0x1a99e4)~0x1e8274)
- disconnect_all= '' at DBI.pm line 565
- DESTROY in DBD::_::common for DBD::ODBC::dr
(DBI::dr=HASH(0x1e8274)
~INNER)
- DESTROY= undef during global destruction
and the driver trace below - shows that certain values are
coming back -
sorry for the length - just wanted to get it all in.
Starting log file with debug level 99.
2002-12-27 17:30:04.500260 Connecting addr 142.178.18.4 port
1433 with TDS
version 4.2
Sending packet @ 2002-12-27 17:30:04.563402
02 00 02 00 00 00 00 00 68 6f 73 74 69 6e 67 00 |
hosting.|
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
|
0020 00 00 00 00 00 00 07 77 65 62 65 78 00 00 00 00
|...xx|
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
|
0040 00 00 00 00 00 05 33 36 32 31 31 38 00 00 00 00
|..xx|
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
|
0060 00 00 00 00 06 33 37 38 37 36 00 00 00 00 00 00 |.378
76..|
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
|
0080 00 00 00 05 02 00 06 04 08 01 00 00 00 00 00 02 |
|
0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
|
00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
|
00b0 00 00 00 53 70 65 63 74 65 6c 42 53 00 00 00 00 |...Spect
elBS|
00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
|
00d0 00 09 33 36 32 31 31 38 00 00 00 00 00 00 00 00 |..xx
RE: text problem with ODBC
Assuming this is the problem, it would be handy if DBD::ODBC followed DBD::Oracle's lead and added a hint to the error message: ... (DBD: st_fetch/SQLFetch (long truncated, DBI attribute LongTruncOk not set and/or LongReadLen too small) ... Done. Jeff
RE: Invalid Precision error
On Mon, 30 Dec 2002 00:12:40 -0500, Jeff Thies wrote: I'm getting a weird error when I try to update a text field (Access, latest ODBC and DBI) sometimes: This is a placeholder problem. Changing the script so the affected field is not a placeholder eliminates the problem. ie: set text_field=? fails *sometimes* while set text_field='$text_field' does not. Where might the problem be? In that case, it sounds like an incorrect guess of the type of variable. Try something like use DBI ':sql_types'; # to import the constants ... $sth = $dbh-prepare($sql); $sth-bind_param(1, undef, SQL_VARCHAR); $sth-execute($value); i.e. inserting an appropriate bind_param call between the prepare and the execute. where you may try one of several constants instead of the SQL_VARCHAR. See the section on DBI Constants in the DBI docs. Sometimes, access needs SQL_LONGVARCHAR or SQL_LONGVARBINARY (depending upon what you are inserting, of course). The bind_param is a good thing to ensure you tell access exactly what you want. Jeff
RE: DBI installation problem
I am not much of an expert on this, but I thought I would pass along a few
hints from the list which were helpful to me in testing and installing DBI.
I got some very timely help from this list - for which I am very grateful
1.Specify the path where you want to install DBI - this should be the same
path where your other perl modules reside, which may or may not be the
default used in the installation.
perl Makefile.PL PREFIX=~/whereYouWantItToGo
You'll also want to make sure that your installation does in fact have the
Time/HiRes.pm module somewhere
2. You may need to specify where your modules are located, so that Makefile
can find them - the way I did it was to insert the 'use lib' directive
directly into the Makefile - Iknow that youare not suposed to do this, but
sometimes practicality has a way of interfering with elegance.
use lib('~/whereTheModulesAre');
This prepends the specified path to @INC.
t/40profile.Can't locate Time/HiRes.pm in @INC (@INC contains:
blib/arch blib/lib /usr/libdata/perl/5.00503/mach /usr/libdata/perl/5.00503
/usr/local/lib/perl5/site_perl/5.005/i386-freebsd
/usr/local/lib/perl5/site_perl/5.005/i386-freebsd
/usr/local/lib/perl5/site_perl/5.005 . /usr/libdata/perl/5.00503/mach
/usr/libdata/perl/5.00503 /usr/local/lib/perl5/site_perl/5.005/i386-freebsd
/usr/local/lib/perl5/site_perl/5.005 . /usr/libdata/perl/5.00503/mach
/usr/libdata/perl/5.00503) at t/40profile.t line 183.
BEGIN failed--compilation aborted at t/40profile.t line 183.
Use of uninitialized value at t/40profile.t line 35.
dubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 1-56
Failed 56/56 tests, 0.00% okay
RE: :ODBC fails during make
Thanks, I loaded a more current driver manager and then the DBD::ODBC installed without any problems Jo :-) -Original Message- From: Jeff Urlwin [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 26, 2002 9:41 AM To: 'Davis, Jo'; [EMAIL PROTECTED] Subject:RE: :ODBC fails during make ODBC.xs:172: `SQL_API_ODBC3_ALL_FUNCTIONS_SIZE' undeclared (first use in this function) ODBC.xs:172: (Each undeclared identifier is reported only once ODBC.xs:172: for each function it appears in.) ODBC.xs:185: `SQL_API_ODBC3_ALL_FUNCTIONS' undeclared (first use in this function) gcc: file path prefix `/usr/ccs/bin/' never used *** Error code 1 make: Fatal error: Command failed for target `ODBC.o' Upgrade your driver manager. Not DBI, but your ODBC driver manager to one that is ODBC version 3 compatible. I would really appreciate it if someone could point me in the right direction to getting this fixed. Thanks. Jdavis [EMAIL PROTECTED]
