RE: :JDBC error - Bareword "SQL_BIGINT" not allowed
Recent versions of DBI removed SQL_BIGINT from it's definition as there was a conflict between SQL/CLI and ODBC's definition. I suspect you need to hack up JDBC.pm to not use it... Regards, Jeff (who ran into this issue with DBD::ODBC) P.S. I take it you want DBD::JDBC due to the thin driver??? > > Set up DBD::JDBC to use a (god help me) a Microsoft supplied JDBC driver > for MS SQL Server 2000. Can't seem to get past the error: > > install_driver(JDBC) failed: Bareword "SQL_BIGINT" not allowed while > "strict subs" in use at /usr/local/lib/perl5/site_perl/5.6.1/DBD/JDBC.pm > line 1028. > BEGIN not safe after errors--compilation aborted at > /usr/local/lib/perl5/site_perl/5.6.1/DBD/JDBC.pm line 1089. > Compilation failed in require at (eval 1) line 3. > > Any ideas on where I went wrong. Thanks, -Marc. > > Marc Francoeur > Sr. Database Administrator > Blue Cross Blue Shield of Kansas City > (816) 395-2674
DBD::JDBC error - Bareword "SQL_BIGINT" not allowed
Set up DBD::JDBC to use a (god help me) a Microsoft supplied JDBC driver for MS SQL Server 2000. Can't seem to get past the error: install_driver(JDBC) failed: Bareword "SQL_BIGINT" not allowed while "strict subs" in use at /usr/local/lib/perl5/site_perl/5.6.1/DBD/JDBC.pm line 1028. BEGIN not safe after errors--compilation aborted at /usr/local/lib/perl5/site_perl/5.6.1/DBD/JDBC.pm line 1089. Compilation failed in require at (eval 1) line 3. Any ideas on where I went wrong. Thanks, -Marc. Marc Francoeur Sr. Database Administrator Blue Cross Blue Shield of Kansas City (816) 395-2674 CONFIDENTIALITY NOTICE: This email massage and any attachments are for the sole use of the intended recipient(s) and may contain proprietary, confidential, trade secret or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited and may be a violation of law. If you are not the intended recipient or a person responsible for delivering this massage to an intended recipient, please contact the sender by reply email and destroy all copies of the original massage.
Re: Sybase connection LD_LIBRARY_PATH problem
On Thu, 2002-08-29 at 15:14, [EMAIL PROTECTED] wrote: > I have a script that connects to a Sybase database, but I'm getting a > relocation error: > I saw in an archive from this list that this was a bug in the Solaris > libintl.so vs Sybase libintl.so and to not have /usr/lib in the > LD_LIBRARY_PATH. If I remove /usr/lib from my LD_LIBRARY_PATH before > running the script, it works fine, but if I try to set the LD_LIBRARY_PATH > in a BEGIN block (without /usr/lib -- see above), it still doesn't work. > Shouldn't it be using the new LD_LIBRARY_PATH? No, you can't set LD_LIBRARY_PATH in the script itself. This environment variable only affects *child* processes of the process where you set it. Michael -- Michael Peppler / [EMAIL PROTECTED] / http://www.mbay.net/~mpeppler [EMAIL PROTECTED] / ZetaTools, Inc / http://www.zetatools.com ZetaTools: Call perl functions as Sybase stored procedures! signature.asc Description: This is a digitally signed message part
RE: Failure of ODBC connection with Access
Ahh...thanks John. I forgot that BINARY_LOCATION needs to be passed when doing perl Makefile.PL, not when doing nmake... I fixed my script and the one up on the ftp site. Regards, Jeff > > > Jeff Urlwin [EMAIL PROTECTED] wrote: > > > >> > >> 2. The perl I use is also Activeperl build 633. I have no idea why I > >> cannot install dbd::odbc succesfully. > > > > I don't know. It might be a flag in the ppd file, but the ppd is > > generated by MakeMaker directly. It also says, in the ppd file, that > > the architecture is > > > > The "DBD-ODBC.ppd" from ftp.esoftmatic.com/outgoing/DBI/. comes with an > empty "codebase href" entry. You need to edit in the *.tar.gz file > location thus: > > then from the DOS Prompt in the directory where the *.ppd and *.tar.gz > files are located type: > ppm remove DBD-ODBC.ppd > to remove any existing DBD-ODBC module, then type: > ppm install DBD-ODBC.ppd > > HTH > > -- > Regards >John McMahon (mailto:[EMAIL PROTECTED]) > > > > > >
Re: Failure of ODBC connection with Access
Jeff Urlwin [EMAIL PROTECTED] wrote: > >> >> 2. The perl I use is also Activeperl build 633. I have no idea why I >> cannot install dbd::odbc succesfully. > > I don't know. It might be a flag in the ppd file, but the ppd is > generated by MakeMaker directly. It also says, in the ppd file, that > the architecture is > The "DBD-ODBC.ppd" from ftp.esoftmatic.com/outgoing/DBI/. comes with an empty "codebase href" entry. You need to edit in the *.tar.gz file location thus: then from the DOS Prompt in the directory where the *.ppd and *.tar.gz files are located type: ppm remove DBD-ODBC.ppd to remove any existing DBD-ODBC module, then type: ppm install DBD-ODBC.ppd HTH -- Regards John McMahon (mailto:[EMAIL PROTECTED])
Re: DBI setup error
On Fri, 30 Aug 2002 13:13:17 +0800 [EMAIL PROTECTED] wrote: > I use your DBI moudle to install in hp server. But, it faill to compile. > Because it use gcc to make compile. > Do you have any version of DBI moudle to use ansi c to compile? > Thanks! > > Here is the error message for your reference. > > % make > /bin/perl -I/opt/perl/lib/5.6.1/PA-RISC1.1-thread-multi > -I/opt/perl/lib/5.6.1 /opt/perl/lib/5.6.1/ExtUtils/xsubpp -typemap > /opt/perl/lib/5.6.1/ExtUtils/typemap Perl.xs > Perl.xsc && mv Perl.xsc > Perl.c > gcc -c -D_POSIX_C_SOURCE=199506L -D_HPUX_SOURCE -L/lib/pa1.1 > -DUINT32_MAX_BROKEN -mpa-risc-1-1 -fPIC -fno-strict-aliasing > -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O > -DVERSION=\"1.30\" -DXS_VERSION=\"1.30\" -fPIC > -I/opt/perl/lib/5.6.1/PA-RISC1.1-thread-multi/CORE -Wall -Wno-comment > Perl.c > sh: gcc: not found. > *** Error exit code 127 You apparently have a copy of perl that was built using gcc. To build DBI, or other modules with binary components, you _MUST_ use the same compiler as was used to build perl. Either install the version of gcc used to build perl (ask whoever provided the perl) or build your own perl from the source archive available on CPAN. If you build your own perl, be sure to read README.hpux before you start. If you intend to use DBD::Oracle, read http:[EMAIL PROTECTED]/msg13027.html and the README.hpux for that module as well before you build anything. -- Mac :}) ** I normally forward private questions to the appropriate mail list. ** Ask Smarter: http://www.tuxedo.org/~esr/faqs/smart-questions.html Give a hobbit a fish and he eats fish for a day. Give a hobbit a ring and he eats fish for an age.
RE: Trying to obtain values passed to bind_param
Hi,
What if you took a look at how trace is implemented? But then again I don't
remember seeing values from any trace level until after the execute with
either.
Eric
At 09:35 AM 8/30/02 -0400, Jeff Urlwin wrote:
>Did you look at the new ParamValues attribute? Yes, many drivers probably
>do not support it yet, but that's what it's for. (Also, DBD::ODBC does
>support it and I believe that even if DBD::Oracle doesn't yet support it a
>small lift of the same/similar code from DBD::ODBC to DBD::Oracle should
>work...
>
>Regards,
>
>Jeff
>>
>> Hello,
>>
>> In an attempt to add some custom logging into DBI calls, I have
>> over-ridden
>> the execute method of DBI with a custom execute method. The
>> project I have
>> includes writing out the SQL statement that is at fault if execute blows
>> up. This needs to be transparent to the user, and must work with all
>> existing DBI code that has been writen.
>>
>> My approach is simple. Override execute, add some error logging if $@
>> returns back anything from an eval calling the real DBI execute.
>> One piece
>> is missing though.
>>
>> While printing out the statement from $pkg->{'STATEMENT'}, the
>> placeholders
>> used (?) ends up coming in literally. This is fine and I wouldn't mind
>> substituting the values passed for the bindings, but I cannot get to the
>> values. Let me clear that up..
>>
>> If the user calls execute, binding the params within the execute,
>> I can get
>> them. They are passed to my execute statement and I can grab
>> them from @_,
>> but if the params are passed using bind_param, I cannot get them, save for
>> overriding the bind_param statement as well (somthing I would rather not
>> do).
>>
>> To make a long story short, I would like to know if there is any way to
>> access the values passed in a bind_param method call.
>>
>> Here is the over-ridden execute method, this works except for the
>> parameter
>> part.
>>
>> Thanks in advance.
>>
>> -Mark
>>
>> sub execute {
>> my $pkg = shift;
>> my $statement = $pkg->{'Statement'};
>>
>> # if RaiseError or PrintError are set to 1 (lets hope), lets make sure
>> # we don't print the DBI error until we are ready to do so.
>> {
>> open TRAP, ">/dev/null";
>> local *STDERR = *TRAP;
>> eval { $pkg->SUPER::execute(@_); };
>> close TRAP;
>> }
>>
>> my @params = @_;
>> my $params = (@params) ? \@params : (
>>my $tmp_p = $pkg->FETCH('driver_params') ? $tmp_p : [] ) ;
>>
>> my $num_of_parms = $pkg->{'NUM_OF_PARAMS'};
>>
>> print "Number of Parameters: $num_of_parms\n";
>> print "Parms = @$params\n";
>> print "Executing Statement -> \n";
>> print "\n".&$pretty_print($statement)."\n";
>>
>> if ($@) {
>> warn "Could not execute statment -> \n";
>> warn "\n".&$pretty_print($statement)."\n";
>> die "$@\n"; # Yes this is intentional, die no matter what.
>> }
>> }
>>
>>
>>
>>
>
>
http://www.kwinternet.com/eric
(250) 655 - 9513 (PST Time Zone)
"Inquiry is fatal to certainty." -- Will Durant
RE: Trying to obtain values passed to bind_param
Did you look at the new ParamValues attribute? Yes, many drivers probably
do not support it yet, but that's what it's for. (Also, DBD::ODBC does
support it and I believe that even if DBD::Oracle doesn't yet support it a
small lift of the same/similar code from DBD::ODBC to DBD::Oracle should
work...
Regards,
Jeff
>
> Hello,
>
> In an attempt to add some custom logging into DBI calls, I have
> over-ridden
> the execute method of DBI with a custom execute method. The
> project I have
> includes writing out the SQL statement that is at fault if execute blows
> up. This needs to be transparent to the user, and must work with all
> existing DBI code that has been writen.
>
> My approach is simple. Override execute, add some error logging if $@
> returns back anything from an eval calling the real DBI execute.
> One piece
> is missing though.
>
> While printing out the statement from $pkg->{'STATEMENT'}, the
> placeholders
> used (?) ends up coming in literally. This is fine and I wouldn't mind
> substituting the values passed for the bindings, but I cannot get to the
> values. Let me clear that up..
>
> If the user calls execute, binding the params within the execute,
> I can get
> them. They are passed to my execute statement and I can grab
> them from @_,
> but if the params are passed using bind_param, I cannot get them, save for
> overriding the bind_param statement as well (somthing I would rather not
> do).
>
> To make a long story short, I would like to know if there is any way to
> access the values passed in a bind_param method call.
>
> Here is the over-ridden execute method, this works except for the
> parameter
> part.
>
> Thanks in advance.
>
> -Mark
>
> sub execute {
> my $pkg = shift;
> my $statement = $pkg->{'Statement'};
>
> # if RaiseError or PrintError are set to 1 (lets hope), lets make sure
> # we don't print the DBI error until we are ready to do so.
> {
> open TRAP, ">/dev/null";
> local *STDERR = *TRAP;
> eval { $pkg->SUPER::execute(@_); };
> close TRAP;
> }
>
> my @params = @_;
> my $params = (@params) ? \@params : (
>my $tmp_p = $pkg->FETCH('driver_params') ? $tmp_p : [] ) ;
>
> my $num_of_parms = $pkg->{'NUM_OF_PARAMS'};
>
> print "Number of Parameters: $num_of_parms\n";
> print "Parms = @$params\n";
> print "Executing Statement -> \n";
> print "\n".&$pretty_print($statement)."\n";
>
> if ($@) {
> warn "Could not execute statment -> \n";
> warn "\n".&$pretty_print($statement)."\n";
> die "$@\n"; # Yes this is intentional, die no matter what.
> }
> }
>
>
>
>
RE: Failure of ODBC connection with Access
>
>
> 1. I am doing everything in my notebook with win2000 and I log on as
> administrator. Apache is started by "apache -f myhttpd.conf -k start".
> Does this mean that the user running apache service is administrator? I
> have checked the DBD::ODBC doc and got no more clues except for defining a
> system DSN which I have done.
Note that I haven ot worked with apache 2.x yet, so what I say is pretty
specific to apache 1.3. Mostly under unix, too, rather than Windows...
That said: IF you start apache from the command line, then yes, it should be
running as your user (if you start it as a service in the "Services" applet,
then check what it says for the user. If you rely upon environment
variable,s apache doesn't pass the environment to the child processes (not
sure if your are using 2.x and threads or 1.x and "forked" processes).
Anyway, from the connect string below, I don't see that you are using
environment variables, so that's probably not it.
Try to use CGI::Carp to get the error message, just to verify what it says
or log the error message to a file when running under the cgi environment.
Just to make sure what the error message is when trying to connect via the
web.
>
> 2. The perl I use is also Activeperl build 633. I have no idea why I
> cannot install dbd::odbc succesfully.
I don't know. It might be a flag in the ppd file, but the ppd is generated
by MakeMaker directly. It also says, in the ppd file, that the architecture
is
Can you verify you are getting that particular ppd by specifying the
full-path on the install line?
>
> Thanks a lot for your patience in dealing with this kind of Most
> Frequently
> Asked Question !
NP, but you should probably cross-post to dbi-users (which I did here) as
you will get a more broad level of support. I don't know everything :)
Jeff
> - Original Message -
> From: "Jeff Urlwin" <[EMAIL PROTECTED]>
> To: "Liu Haifeng" <[EMAIL PROTECTED]>; "Jeff Urlwin"
> <[EMAIL PROTECTED]>
> Sent: Thursday, August 29, 2002 6:47 PM
> Subject: RE: Failure of ODBC connection with Access
>
>
> > > Hi Jeff,
> > >
> > > Now I am trying to let my code working as a cgi script. The
> web server
> > > (apache) is running locally at the same machine. The code failed
> > > to connect
> > > to the database again (using system DSN which works in the
> command line
> > > enviornment). The snippet is the same as the earlier one:
> > > .
> > > my $dbn="newgene";
> > > my $dbh=DBI->connect("dbi:ODBC:$dbn",'','')|| die
> "err:$DBI::errstr\n";
> > >
> > > my $cur=$dbh->prepare('select name from clients');
> > > print "there are $cur->{NUM_OF_FIELDS} fields \n";
> > > $cur->execute();
> > > while (my @row =$cur->fetchrow){
> > > print "$row[0] \n";
> > > }
> > > $dbh->disconnect();
> >
> > Is apache running as a service? If so, check who the user running the
> > service is. If it's LOCALSYSTEM (the default), then you get no
> access to
> > network shares. If you are on a domain, it probably needs to
> be a domain
> > user (although you can make it a local user and work out the
> permissions,
> > it's MUCH easier to make it a domain user. Some of this is described in
> the
> > PERL FAQ and DBD::ODBC's POD (from the command line, perldoc DBD::ODBC)
> >
> > > .
> > >
> > > I have checked the archive of the mailinglist and found one similar
> case.
> > > As you suggested, I download the updated dbi.ppd and dbd-odbc.ppd from
> > > ftp.esoftmatic.com/outgoing/DBI/. However, I failed to install
> > > dbd-odbc.ppd while dbi.ppd was successfully installed using
> ppm. When I
> > > type "ppm install dbd-odbc.ppd", it says:
> > >
> > > Installing package 'dbd-odbc.ppd' ...
> > > Error installing package 'dbd-odbc.ppd': Read a PPD fro
> > > 'dbd-odbc.ppd', but
> > > it is not intended for this build of Perl (MSWin32-x86-multi-thread)
> > >
> > > Does this mean that I have to reinstall my perl with another version
> (the
> > > current one is v5.6.1 for MSWin32-x86-multi-thread)?
> >
> > I built that with ActivePerl 633, I think. Please check which
> version you
> > are running.
> >
> > Regards,
> >
> > Jeff
> > >
> > > Regards
> > > Haifeng
> > > - Original Message -
> > > From: "Jeff Urlwin" <[EMAIL PROTECTED]>
> > > To: "Liu Haifeng" <[EMAIL PROTECTED]>; "Jeff Urlwin"
> > > <[EMAIL PROTECTED]>
> > > Sent: Thursday, August 29, 2002 11:03 AM
> > > Subject: RE: Failure of ODBC connection with Access
> > >
> > >
> > > > To verify: the system DSN worked, so we are down to looking at the
> > > DSN-less
> > > > connection, right?
> > > >
> > > > I'll presume this is from the command line rather than from a web
> server
> > > or
> > > > service of some sort, right (the service/web server environment
> > > *usually*
> > > > causes issues).
> > > >
> > > > A few things come to mind:
> > > > 1) As I recall, the bug in DBD::ODBC 0.28 when connecting with
> > > a DSN-less
> > > > connection string was that the error message became invalid
> > > string buffer
> > >
DBI setup error
Hi, Sorry to bother you! I use your DBI moudle to install in hp server. But, it faill to compile. Because it use gcc to make compile. Do you have any version of DBI moudle to use ansi c to compile? Thanks! Here is the error message for your reference. % make /bin/perl -I/opt/perl/lib/5.6.1/PA-RISC1.1-thread-multi -I/opt/perl/lib/5.6.1 /opt/perl/lib/5.6.1/ExtUtils/xsubpp -typemap /opt/perl/lib/5.6.1/ExtUtils/typemap Perl.xs > Perl.xsc && mv Perl.xsc Perl.c gcc -c -D_POSIX_C_SOURCE=199506L -D_HPUX_SOURCE -L/lib/pa1.1 -DUINT32_MAX_BROKEN -mpa-risc-1-1 -fPIC -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O-DVERSION=\"1.30\" -DXS_VERSION=\"1.30\" -fPIC -I/opt/perl/lib/5.6.1/PA-RISC1.1-thread-multi/CORE -Wall -Wno-comment Perl.c sh: gcc: not found. *** Error exit code 127 Stop. Best Regards, Joseph Huang(¶À¬R»Ê) Philips Semiconductor Kaohsiung (PSK) Internet: [EMAIL PROTECTED] TEL:886-7-3612511 DECT:8195 FAX:886-7-3646825
