Re: DBD::Sybase and DBI->get_info()
On Jun 3, 2011, at 9:58 PM,
wrote:
> Thanks, John.
>
> If anyone can comment with authority on the lack of intraspection
> capabilities in DBD::Sybase, that'd be helpful. I looked through the code as
> well, and didn't find anything to say one way or another. Get_info() appears
> to be relatively new to DBI, and it look slike there is some facility to
> generate the code required to populate get_info() for your DBD's, but nothing
> that says one way or another if there is actually any way to get info form
> the driver.
>
> Hoping someone can help here. We are currently running DBD::Sybase for
> Sybase and moving toward using DBD::ODBC for MSSQL instead of using FreeTDS
> under DBD::Sybase for MS SQL. IN any case, it would be particularly helpful
> if we could ask the driver object what type of DB it's a connection handle to.
There are a couple of things you could try - maybe see if any of the
private/driver specific methods are available.
Or something like $dbh->{syb_oc_version}, which if it returns something will at
least identify the driver handle as being a DBD::Sybase handle using Sybase
OpenClient. If you are using DBD::Sybase with FreeTDS then you may need to use
another private attribute, maybe something like
defined($dbh->{syb_dyn_supported}).
Michael
--
Michael Peppler
Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
"A successful [software] tool is one that was used to do something undreamed of
by its author." -- S. C. Johnson
RE: Need Help with DBI for oracle
Ganesh,
Try updating your value for $dsn this way:
- Instead of using this:
>
> $dsn = 'dbi:Oracle:$database:in-gh01:1521';
>
- Try using this:
$dsn = "dbi:Oracle:host=in-gh01:sid=$database";
Please make note of the use of double-quotes ("") instead of
single-quotes ('') in my example. It will ensure the variable
containing the name of the database/SID gets expanded when the
statement is evaluated, instead of being interpreted as a literal.
Good luck!
Marcus
> -Original Message-
> From: Ganesh Bendre [mailto:ganesh.b.ben...@gmail.com]
> Sent: Thursday, June 02, 2011 9:48 AM
> To: dbi-users@perl.org
> Subject: Need Help with DBI for oracle
>
> Hi,
>
> I am using the following code for fetching some data.
> but not able to connect
>
> *CODE:*
> #!C:/Perl/bin/perl.exe
>
> use DBI;
> use DBD::Oracle;
>
> print "Content-type: text/html \n\n";
>
> $platform = "ORACLE";
> $database = "I8Q.GRP.COM";
> $tablename = "COUNTY_ADD";
> $user = "dba";
> $pw = "dbapass";
>
> $dsn = 'dbi:Oracle:$database:in-gh01:1521';
>
> $connect = DBI->connect($dsn, $user, $pw);
>
> $query = "select ctycode,ctydesc from county_add";
> $query_handle = $connect->prepare($query);
>
> $query_handle->execute();
>
> $query_handle->bind_columns(undef, \$ctycode, \$ctydesc);
>
> while($query_handle->fetch()) {
>print "$ctycode, $ctydesc ";
> }
> *CODE END*
> **
> **
> I am getting the following error when i try to run the above code
> **
> *Error:*
> DBI connect('$database:in-gh01:1521','dba',...) failed:
> ORA-06401: NETCMN:
> id driver designator (DBD ERROR: OCIServerAttach) at
> exequery2.pl line 21 Can't call method "prepare" on an
> undefined value at exequery2.pl line 25.
> *Error END*
>
> *I have installed *
> *DBD::Oracle*
> *DBI*
> **
> **
> *i am stuck with this for almost one week Please help me out*
> **
> *Ganesh.*
> **
>
RE: DBD::Sybase and DBI->get_info()
Thanks, John. If anyone can comment with authority on the lack of intraspection capabilities in DBD::Sybase, that'd be helpful. I looked through the code as well, and didn't find anything to say one way or another. Get_info() appears to be relatively new to DBI, and it look slike there is some facility to generate the code required to populate get_info() for your DBD's, but nothing that says one way or another if there is actually any way to get info form the driver. Hoping someone can help here. We are currently running DBD::Sybase for Sybase and moving toward using DBD::ODBC for MSSQL instead of using FreeTDS under DBD::Sybase for MS SQL. IN any case, it would be particularly helpful if we could ask the driver object what type of DB it's a connection handle to. From: John Scoles [mailto:byter...@hotmail.com] Sent: Friday, June 03, 2011 11:46 AM To: Berg, Eric: IT (NYK); dbi-users@perl.org Subject: RE: DBD::Sybase and DBI->get_info() Well looking at the code there does not seem to be any get_info in DBD::Sybase so I think you are out of luck Cheers John > From: eric.b...@barclayscapital.com > To: dbi-users@perl.org > Date: Fri, 3 Jun 2011 11:38:59 -0400 > Subject: DBD::Sybase and DBI->get_info() > > As we migrate our codebase from Sybase (DBD::Sybase) to MS SQL (DBD::ODBC), > it would be helpful to have low-level info about the drivers available, and > it seems that the DBI->get_info() method is the place to go for that. It is > supported adequately in DBD::ODBC, but it appears that DBD::Sybase doesn't > support get_info(). > > Am I missing something about using get_info(), or does DBD::Sybase provide > low-level driver info another way? > > Any idea how to get info out of DBD::Sybase? > > Thanks. > > Eric > > ___ > > This e-mail may contain information that is confidential, privileged or > otherwise protected from disclosure. If you are not an intended recipient of > this e-mail, do not duplicate or redistribute it by any means. Please delete > it and any attachments and notify the sender that you have received it in > error. Unless specifically indicated, this e-mail is not an offer to buy or > sell or a solicitation to buy or sell any securities, investment products or > other financial product or service, an official confirmation of any > transaction, or an official statement of Barclays. Any views or opinions > presented are solely those of the author and do not necessarily represent > those of Barclays. This e-mail is subject to terms available at the following > link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent > to the foregoing. Barclays Capital is the investment banking division of > Barclays Bank PLC, a company registered in England (number 1026167) with its > registered office at 1 Churchill Place, London, E14 5HP. This email may > relate to or be sent from other members of the Barclays Group. > ___ ___ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ___
Re: can $dbh->do take a prepared statement handle?
=pod
if you've got enough control over the flow of control to have the code below
work safely, you probably don't need it
=cut
sub Super_do($){
if (ref $_[0]){
$_[0]->execute();
}else{
$dbh->do($_[0]);
}
};
RE: Assigning private attributes to DBI database handles
Perfect, Martin. That's just what I needed. I spent an hour or so looking for this, because I knew it was there somewhere. Must have read everything up to that one in the DBI docs. Thanks again. > -Original Message- > From: Martin J. Evans [mailto:martin.ev...@easysoft.com] > Sent: Friday, June 03, 2011 2:39 PM > To: Berg, Eric: IT (NYK) > Cc: dbi-users@perl.org > Subject: Re: Assigning private attributes to DBI database handles > > On 03/06/2011 19:30, eric.b...@barclayscapital.com wrote: > > I'd like to set some private attributes on my db handles so that later I > can interrogate them to get that information. > > > > We are doing this with statement handles, but not DB handles, and it > simply doesn't seem to be working in any case. > > > > Any thoughts? > > > > Eric > > > Did you read > http://search.cpan.org/~timb/DBI-1.616/DBI.pm#private_your_module_name_* > > and are you doing this. It might help to know what you've tried. > > Martin ___ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ___
Re: can $dbh->do take a prepared statement handle?
On Fri, Jun 3, 2011 at 12:06, Jeff Macdonald wrote: > can $dbh->do take a prepared statement handle? > No. See 'perldoc DBI'. -- Jonathan Leffler #include Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
RE: DBD::ODBC Segfaults on SET TEXTSIZE and TRUNCATE TABLE
Yes! Thanks for the clarification, Martin.
Folks, I've had an opportunity to work with Martin and a few others on the
EasySoft team on this and a few other problems, and I want you to know that
they've been really helpful.
As a long-time OSS guy, I'm highly suspicious of proprietary software and the
companies that "support" them, but EasySoft has been a great partner. They're
knowledgeable, helpful and responsive, even considering that they're
...ehem...not in the US. This has been a really good experience, and I wanted
to pass that on to the DBI community. Two thumbs up!
Eric
> -Original Message-
> From: Martin J. Evans [mailto:martin.ev...@easysoft.com]
> Sent: Friday, June 03, 2011 2:54 PM
> To: dbi-users@perl.org
> Subject: Re: DBD::ODBC Segfaults on SET TEXTSIZE and TRUNCATE TABLE
>
> On 03/06/2011 19:21, bergbrains wrote:
> > The resolution of this issue was to rebuild DBD::ODBC, using an
> > available odbc_config, which correctly informed the build that it
> > should use 64-bit, instead of its defaulting to 32-bit. That cleared
> > up all of these segfault issues.
> >
> I'm pleased to hear that.
>
> Just to make this clear in the hope others don't fall into this problem...
>
> unixODBC contains sql*.h header files which depend on configure. As a
> result they contain things like:
>
> #if (SIZEOF_LONG_INT == 4)
> typedef unsigned long DWORD;
> #else
> typedef unsigned intDWORD;
> #endif
>
> there are other instances of this. configure sets SIZEOF_LONG_INT when
> you configure and build unixODBC so all is well when you build unixODBC.
> However, after you've built unixODBC and installed those sql*.h header
> files any application built against unixODBC needs to have
> SIZEOF_LONG_INT set the same as it was when unixODBC was built.
>
> If you don't have an ancient version of unixODBC (and unfortunately,
> some Linux distros in particular contain ancient versions of unixODBC)
> you don't have the odbc_config program and DBD::ODBC looks for
> odbc_config to run its --cflags argument which returns a list of defines
> unixODBC was built with. If DBD::ODBC does not find odbc_config it has
> no idea how unixODBC was built and so you can get a DBD::ODBC which has
> some types expecting 4 bytes when in unixODBC they are 8 bytes (leading
> to corruption). Now, I could just change DBD::ODBC to refuse to build in
> this case but as few Linux distros contain anything other than an
> ancient unixODBC I'd get inundated with people complaining it does not
> build (on 32bit platforms) when in fact it makes little difference to
> them and only affects 64bit platforms.
>
> More recent versions (not that recent actually) of unixODBC contain
> odbc_config and that should work. Even more recent versions of unixODBC
> contain header files that require SIZEOF_LONG_INT to be defined or they
> baulk.
>
> I think this was all covered in previous posts but just to make sure.
>
> Martin
> > On May 17, 2:06 pm, martin.ev...@easysoft.com ("Martin J. Evans")
> > wrote:
> >> On 17/05/2011 14:54, eric.b...@barclayscapital.com wrote:> Just a
> quick update:
> >>
> >>> We switched back to using the FreeTDS driver under DBD::ODBC with the
> unixODBC ODBC manager on Linux and the segfault problem went away.
> >>> That seems to suggest to me that it's a problem with the Easysoft
> driver, and I've communicated this to the Easysoft team.
> >>> BTW, the Easysoft guys have been really terrific; responsive and
> knowledgeable. A real pleasure to work with. Hopefully they can track
> down this bug.
> >>> Eric
> >> Eric, I believe Easysoft support are sorting you out but as the problem
> >> I believe you've hit potentially affects anyone else using an older
> >> unixODBC on 64 bit platforms (or one without odbc_config) it is worth
> >> mentioning it here.
> >>
> >> Some background:
> >>
> >> As many of you may know MS invented ODBC and then I believe handed it
> >> over to X/Open. However, since then they have continued making changes
> >> to the API. Before Windows 64 bit operating systems many ODBC APIs were
> >> documented as taking or returning 32 bits values (and I mean that, not
> >> int or long but documented as a 32 bit value which is strange for a C
> >> API). When Windows 64 came along some APIs were changed to take an
> >> SQLLEN/SQLULEN or a pointer to a SQLLEN/SQLULEN and an SQLLEN/SQLULEN
> >> was defined as 32 bits on 32 bit operating systems and 64 bits on 64
> bit
> >> operating systems.
> >>
> >> unixODBC and many ODBC drivers who were ahead of MS and building
> drivers
> >> and driver managers for 64bit platforms could not know what MS were
> >> going to do and they did not all make the same choice. Most stuck with
> >> the API as it was which said 32 bit values. When MS changed ODBC to
> >> introduce SQLLEN/SQLULEN it left some driver writers with a problem and
> >> some had to produce 2 versions of their 64bit drivers - one using 32bit
> >> values for some ODBC API pa
can $dbh->do take a prepared statement handle?
subject says it all. TIA -- Jeff Macdonald Ayer, MA
Re: DBD::ODBC Segfaults on SET TEXTSIZE and TRUNCATE TABLE
On 03/06/2011 19:21, bergbrains wrote:
The resolution of this issue was to rebuild DBD::ODBC, using an
available odbc_config, which correctly informed the build that it
should use 64-bit, instead of its defaulting to 32-bit. That cleared
up all of these segfault issues.
I'm pleased to hear that.
Just to make this clear in the hope others don't fall into this problem...
unixODBC contains sql*.h header files which depend on configure. As a
result they contain things like:
#if (SIZEOF_LONG_INT == 4)
typedef unsigned long DWORD;
#else
typedef unsigned intDWORD;
#endif
there are other instances of this. configure sets SIZEOF_LONG_INT when
you configure and build unixODBC so all is well when you build unixODBC.
However, after you've built unixODBC and installed those sql*.h header
files any application built against unixODBC needs to have
SIZEOF_LONG_INT set the same as it was when unixODBC was built.
If you don't have an ancient version of unixODBC (and unfortunately,
some Linux distros in particular contain ancient versions of unixODBC)
you don't have the odbc_config program and DBD::ODBC looks for
odbc_config to run its --cflags argument which returns a list of defines
unixODBC was built with. If DBD::ODBC does not find odbc_config it has
no idea how unixODBC was built and so you can get a DBD::ODBC which has
some types expecting 4 bytes when in unixODBC they are 8 bytes (leading
to corruption). Now, I could just change DBD::ODBC to refuse to build in
this case but as few Linux distros contain anything other than an
ancient unixODBC I'd get inundated with people complaining it does not
build (on 32bit platforms) when in fact it makes little difference to
them and only affects 64bit platforms.
More recent versions (not that recent actually) of unixODBC contain
odbc_config and that should work. Even more recent versions of unixODBC
contain header files that require SIZEOF_LONG_INT to be defined or they
baulk.
I think this was all covered in previous posts but just to make sure.
Martin
On May 17, 2:06 pm, martin.ev...@easysoft.com ("Martin J. Evans")
wrote:
On 17/05/2011 14:54, eric.b...@barclayscapital.com wrote:> Just a quick update:
We switched back to using the FreeTDS driver under DBD::ODBC with the unixODBC
ODBC manager on Linux and the segfault problem went away.
That seems to suggest to me that it's a problem with the Easysoft driver, and
I've communicated this to the Easysoft team.
BTW, the Easysoft guys have been really terrific; responsive and knowledgeable.
A real pleasure to work with. Hopefully they can track down this bug.
Eric
Eric, I believe Easysoft support are sorting you out but as the problem
I believe you've hit potentially affects anyone else using an older
unixODBC on 64 bit platforms (or one without odbc_config) it is worth
mentioning it here.
Some background:
As many of you may know MS invented ODBC and then I believe handed it
over to X/Open. However, since then they have continued making changes
to the API. Before Windows 64 bit operating systems many ODBC APIs were
documented as taking or returning 32 bits values (and I mean that, not
int or long but documented as a 32 bit value which is strange for a C
API). When Windows 64 came along some APIs were changed to take an
SQLLEN/SQLULEN or a pointer to a SQLLEN/SQLULEN and an SQLLEN/SQLULEN
was defined as 32 bits on 32 bit operating systems and 64 bits on 64 bit
operating systems.
unixODBC and many ODBC drivers who were ahead of MS and building drivers
and driver managers for 64bit platforms could not know what MS were
going to do and they did not all make the same choice. Most stuck with
the API as it was which said 32 bit values. When MS changed ODBC to
introduce SQLLEN/SQLULEN it left some driver writers with a problem and
some had to produce 2 versions of their 64bit drivers - one using 32bit
values for some ODBC API parameters and one using 64bit values as there
were apps out there doing both.
These days unixODBC supports SQLLEN/SQLULEN and most drivers do and
unixODBC builds out the box with a 64bit SQLLEN/SQLULEN value. However,
this is ascertained at configure time and the header files which go with
unixODBC define SQLLEN/SQLULEN as 32bit or 64bit depending on whether
SIZEOF_LONG_INT is 32 or 64. DBD::ODBC looks for unixODBC's odbc_config
program which can be used to return the cc flags used to build unixODBC
and one of those flags is -DSIZEOF_LONG_INT=64. When DBD::ODBC finds
odbc_config it can add the right flags to the compiler when building
DBD::ODBC. When DBD::ODBC cannot find odbc_config (and it goes out of
its way to find it) it cannot know what to add to the compile line so
adds nothing. The result is that if you build DBD::ODBC on a 64bit
platform against unixODBC and odbc_config is not found SQLLEN/SQLULEN
will be 32 bits in size (incorrectly most of the time) and then APIs
like SQLRowCount which is passed a pointer to a SQLLEN will pass a
pointe
Re: Assigning private attributes to DBI database handles
On 03/06/2011 19:30, eric.b...@barclayscapital.com wrote: I'd like to set some private attributes on my db handles so that later I can interrogate them to get that information. We are doing this with statement handles, but not DB handles, and it simply doesn't seem to be working in any case. Any thoughts? Eric Did you read http://search.cpan.org/~timb/DBI-1.616/DBI.pm#private_your_module_name_* and are you doing this. It might help to know what you've tried. Martin
Assigning private attributes to DBI database handles
I'd like to set some private attributes on my db handles so that later I can interrogate them to get that information. We are doing this with statement handles, but not DB handles, and it simply doesn't seem to be working in any case. Any thoughts? Eric ___ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ___
Re: DBD::ODBC Segfaults on SET TEXTSIZE and TRUNCATE TABLE
The resolution of this issue was to rebuild DBD::ODBC, using an
available odbc_config, which correctly informed the build that it
should use 64-bit, instead of its defaulting to 32-bit. That cleared
up all of these segfault issues.
On May 17, 2:06 pm, martin.ev...@easysoft.com ("Martin J. Evans")
wrote:
> On 17/05/2011 14:54, eric.b...@barclayscapital.com wrote:> Just a quick
> update:
>
> > We switched back to using the FreeTDS driver under DBD::ODBC with the
> > unixODBC ODBC manager on Linux and the segfault problem went away.
>
> > That seems to suggest to me that it's a problem with the Easysoft driver,
> > and I've communicated this to the Easysoft team.
>
> > BTW, the Easysoft guys have been really terrific; responsive and
> > knowledgeable. A real pleasure to work with. Hopefully they can track
> > down this bug.
>
> > Eric
>
> Eric, I believe Easysoft support are sorting you out but as the problem
> I believe you've hit potentially affects anyone else using an older
> unixODBC on 64 bit platforms (or one without odbc_config) it is worth
> mentioning it here.
>
> Some background:
>
> As many of you may know MS invented ODBC and then I believe handed it
> over to X/Open. However, since then they have continued making changes
> to the API. Before Windows 64 bit operating systems many ODBC APIs were
> documented as taking or returning 32 bits values (and I mean that, not
> int or long but documented as a 32 bit value which is strange for a C
> API). When Windows 64 came along some APIs were changed to take an
> SQLLEN/SQLULEN or a pointer to a SQLLEN/SQLULEN and an SQLLEN/SQLULEN
> was defined as 32 bits on 32 bit operating systems and 64 bits on 64 bit
> operating systems.
>
> unixODBC and many ODBC drivers who were ahead of MS and building drivers
> and driver managers for 64bit platforms could not know what MS were
> going to do and they did not all make the same choice. Most stuck with
> the API as it was which said 32 bit values. When MS changed ODBC to
> introduce SQLLEN/SQLULEN it left some driver writers with a problem and
> some had to produce 2 versions of their 64bit drivers - one using 32bit
> values for some ODBC API parameters and one using 64bit values as there
> were apps out there doing both.
>
> These days unixODBC supports SQLLEN/SQLULEN and most drivers do and
> unixODBC builds out the box with a 64bit SQLLEN/SQLULEN value. However,
> this is ascertained at configure time and the header files which go with
> unixODBC define SQLLEN/SQLULEN as 32bit or 64bit depending on whether
> SIZEOF_LONG_INT is 32 or 64. DBD::ODBC looks for unixODBC's odbc_config
> program which can be used to return the cc flags used to build unixODBC
> and one of those flags is -DSIZEOF_LONG_INT=64. When DBD::ODBC finds
> odbc_config it can add the right flags to the compiler when building
> DBD::ODBC. When DBD::ODBC cannot find odbc_config (and it goes out of
> its way to find it) it cannot know what to add to the compile line so
> adds nothing. The result is that if you build DBD::ODBC on a 64bit
> platform against unixODBC and odbc_config is not found SQLLEN/SQLULEN
> will be 32 bits in size (incorrectly most of the time) and then APIs
> like SQLRowCount which is passed a pointer to a SQLLEN will pass a
> pointer to 4 bytes of space instead of 8 - thus corrupting the stack.
>
> Now, whether your app (or DBD::ODBC or Perl) will segfault or when it
> will segfault is just pot luck. It is not a driver bug but a bug in the
> building of DBD::ODBC in a way incompatible with unixODBC.
>
> As a side note to anyone looking after packages for Linux especially
> like Ubuntu, Debian etc. Please, please upgrade unixODBC in your package
> system to a newer version AND include odbc_config.
>
> I am sorry this has caused you some problems. I will try and change
> DBD::ODBC to issue a warning on 64 bit platforms if odbc_config is not
> found but as few people pay much attention to the warnings I'm not sure
> what good it will do.
>
> Martin
>
> >> -Original Message-
> >> From: Berg, Eric: IT (NYK)
> >> Sent: Friday, May 13, 2011 9:24 AM
> >> To: 'Martin J. Evans'
> >> Cc: dbi-us...@perl.org
> >> Subject: RE: DBD::ODBC Segfaults on SET TEXTSIZE and TRUNCATE TABLE
>
> >> Thanks, Martin. I've been working with Richard on this for a few days and
> >> he's been very helpful. Just not sure what's up here yet, but it was
> >> recommended that I upgrade from the 1.3 version that we've got packaged
> >> for use here at the bank to 1.4. We'll see if that makes a difference.
>
> >> Many of the tests of DBD::ODBC are failing as well. I'm looking at that,
> >> will upgrade and report my progress back to the list.
>
> >> Thanks again.
>
> >>> -Original Message-
> >>> From: Martin J. Evans [mailto:martin.ev...@easysoft.com]
> >>> Sent: Friday, May 13, 2011 3:46 AM
> >>> To: Berg, Eric: IT (NYK)
> >>> Cc: dbi-us...@perl.org
> >>> Subject: Re: DBD::ODBC Segfaults on SET TEXTSIZE and TRUNCATE TABLE
>
> >>> On
RE: perl DBI Oracle NCLOB fetching
That only ocures when the nclob going in is not compatiable with the nclob field you are trying to stuff it into. one thing that wil give us a little more info is to connect with dbd_verbose=9 on the attributes and that will tell us you NSL setting. also get your DBA to check NLS_CHARACTERSET NLS_NCHAR_CHARACTERSET NLS_LANGUAGE NLS_TERRITORY These should all match up. Your DBI is rather old what is you version of DBD::Oracle you might want to upgrade both Cheers John > Date: Fri, 3 Jun 2011 19:03:46 +0200 > From: y...@mailueberfall.de > To: dbi-users@perl.org > Subject: perl DBI Oracle NCLOB fetching > > Hello, > > my Perl script uses uses the DBI interface to connect to Oracle and runs > a select statement. But if one column is of type NCLOB it fails with: > > DBD::Oracle::st fetchrow_hashref failed: ORA-24806: LOB form mismatch > (DBD ERROR: OCILobRead) [for Statement "SELECT * FROM ttt WHERE ROWNUM=1"] > > I googled a lot and didn't found any solution for it. According to the > used versions of Perl, DBI and Oracle and the NLS settings it should work. > > Any idea how to get it working? > > Here are my used versions: > > DBI::VERSION = "1.41" > perl, v5.8.0 > > SQL> desc ttt > Name Null? Type > > T1 NCLOB > UMSISDN VARCHAR2(200 CHAR) > SPARTID NUMBER(2) > > bash-3.00$ env | grep -i nls > NLS_LANG=AMERICAN_AMERICA.UTF8 > NLSPATH=:/export/home/omni/locale/%L/%N.cat:/export/home/omni/locale/%L/%N > > Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production > > much thanks, > yoyo >
perl DBI Oracle NCLOB fetching
Hello, my Perl script uses uses the DBI interface to connect to Oracle and runs a select statement. But if one column is of type NCLOB it fails with: DBD::Oracle::st fetchrow_hashref failed: ORA-24806: LOB form mismatch (DBD ERROR: OCILobRead) [for Statement "SELECT * FROM ttt WHERE ROWNUM=1"] I googled a lot and didn't found any solution for it. According to the used versions of Perl, DBI and Oracle and the NLS settings it should work. Any idea how to get it working? Here are my used versions: DBI::VERSION = "1.41" perl, v5.8.0 SQL> desc ttt Name Null? Type T1 NCLOB UMSISDN VARCHAR2(200 CHAR) SPARTID NUMBER(2) bash-3.00$ env | grep -i nls NLS_LANG=AMERICAN_AMERICA.UTF8 NLSPATH=:/export/home/omni/locale/%L/%N.cat:/export/home/omni/locale/%L/%N Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production much thanks, yoyo
RE: DBD::Sybase and DBI->get_info()
Well looking at the code there does not seem to be any get_info in DBD::Sybase so I think you are out of luck Cheers John > From: eric.b...@barclayscapital.com > To: dbi-users@perl.org > Date: Fri, 3 Jun 2011 11:38:59 -0400 > Subject: DBD::Sybase and DBI->get_info() > > As we migrate our codebase from Sybase (DBD::Sybase) to MS SQL (DBD::ODBC), > it would be helpful to have low-level info about the drivers available, and > it seems that the DBI->get_info() method is the place to go for that. It is > supported adequately in DBD::ODBC, but it appears that DBD::Sybase doesn't > support get_info(). > > Am I missing something about using get_info(), or does DBD::Sybase provide > low-level driver info another way? > > Any idea how to get info out of DBD::Sybase? > > Thanks. > > Eric > > ___ > > This e-mail may contain information that is confidential, privileged or > otherwise protected from disclosure. If you are not an intended recipient of > this e-mail, do not duplicate or redistribute it by any means. Please delete > it and any attachments and notify the sender that you have received it in > error. Unless specifically indicated, this e-mail is not an offer to buy or > sell or a solicitation to buy or sell any securities, investment products or > other financial product or service, an official confirmation of any > transaction, or an official statement of Barclays. Any views or opinions > presented are solely those of the author and do not necessarily represent > those of Barclays. This e-mail is subject to terms available at the following > link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent > to the foregoing. Barclays Capital is the investment banking division of > Barclays Bank PLC, a company registered in England (number 1026167) with its > registered office at 1 Churchill Place, London, E14 5HP. This email may > relate to or be sent from other members of the Barclays Group. > ___
DBD::Sybase and DBI->get_info()
As we migrate our codebase from Sybase (DBD::Sybase) to MS SQL (DBD::ODBC), it would be helpful to have low-level info about the drivers available, and it seems that the DBI->get_info() method is the place to go for that. It is supported adequately in DBD::ODBC, but it appears that DBD::Sybase doesn't support get_info(). Am I missing something about using get_info(), or does DBD::Sybase provide low-level driver info another way? Any idea how to get info out of DBD::Sybase? Thanks. Eric ___ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ___
RE: Need Help with DBI for oracle
Simple connection problem.
Try to connect SQLPlus if you can do that then you can use DBD::Oracel
Try the same connection string in DBD:Oracle
Hope this helps
cheers
John
> CC: dbi-users@perl.org
> From: jona...@gmail.com
> Subject: Re: Need Help with DBI for oracle
> Date: Fri, 3 Jun 2011 16:05:23 +0200
> To: ganesh.b.ben...@gmail.com
>
> As you can read from the error message is not interpolated, exchange the
> single quotes for double quotes. Sorry for the abrupt response, but I am in
> transit
>
> jonasbn
>
> Sent from my iPhone
>
> On 02/06/2011, at 15.47, Ganesh Bendre wrote:
>
> > Hi,
> >
> > I am using the following code for fetching some data.
> > but not able to connect
> >
> > *CODE:*
> > #!C:/Perl/bin/perl.exe
> >
> > use DBI;
> > use DBD::Oracle;
> >
> > print "Content-type: text/html \n\n";
> >
> > $platform = "ORACLE";
> > $database = "I8Q.GRP.COM";
> > $tablename = "COUNTY_ADD";
> > $user = "dba";
> > $pw = "dbapass";
> >
> > $dsn = 'dbi:Oracle:$database:in-gh01:1521';
> >
> > $connect = DBI->connect($dsn, $user, $pw);
> >
> > $query = "select ctycode,ctydesc from county_add";
> > $query_handle = $connect->prepare($query);
> >
> > $query_handle->execute();
> >
> > $query_handle->bind_columns(undef, \$ctycode, \$ctydesc);
> >
> > while($query_handle->fetch()) {
> > print "$ctycode, $ctydesc ";
> > }
> > *CODE END*
> > **
> > **
> > I am getting the following error when i try to run the above code
> > **
> > *Error:*
> > DBI connect('$database:in-gh01:1521','dba',...) failed: ORA-06401: NETCMN:
> > id driver designator (DBD ERROR: OCIServerAttach) at exequery2.pl line 21
> > Can't call method "prepare" on an undefined value at exequery2.pl line 25.
> > *Error END*
> >
> > *I have installed *
> > *DBD::Oracle*
> > *DBI*
> > **
> > **
> > *i am stuck with this for almost one week
> > Please help me out*
> > **
> > *Ganesh.*
> > **
Re: Need Help with DBI for oracle
As you can read from the error message is not interpolated, exchange the single
quotes for double quotes. Sorry for the abrupt response, but I am in transit
jonasbn
Sent from my iPhone
On 02/06/2011, at 15.47, Ganesh Bendre wrote:
> Hi,
>
> I am using the following code for fetching some data.
> but not able to connect
>
> *CODE:*
> #!C:/Perl/bin/perl.exe
>
> use DBI;
> use DBD::Oracle;
>
> print "Content-type: text/html \n\n";
>
> $platform = "ORACLE";
> $database = "I8Q.GRP.COM";
> $tablename = "COUNTY_ADD";
> $user = "dba";
> $pw = "dbapass";
>
> $dsn = 'dbi:Oracle:$database:in-gh01:1521';
>
> $connect = DBI->connect($dsn, $user, $pw);
>
> $query = "select ctycode,ctydesc from county_add";
> $query_handle = $connect->prepare($query);
>
> $query_handle->execute();
>
> $query_handle->bind_columns(undef, \$ctycode, \$ctydesc);
>
> while($query_handle->fetch()) {
> print "$ctycode, $ctydesc ";
> }
> *CODE END*
> **
> **
> I am getting the following error when i try to run the above code
> **
> *Error:*
> DBI connect('$database:in-gh01:1521','dba',...) failed: ORA-06401: NETCMN:
> id driver designator (DBD ERROR: OCIServerAttach) at exequery2.pl line 21
> Can't call method "prepare" on an undefined value at exequery2.pl line 25.
> *Error END*
>
> *I have installed *
> *DBD::Oracle*
> *DBI*
> **
> **
> *i am stuck with this for almost one week
> Please help me out*
> **
> *Ganesh.*
> **
