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 ganesh.b.ben...@gmail.com 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 br /;
}
*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
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 ganesh.b.ben...@gmail.com 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 br /;
}
*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.*
**
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: 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. ___
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: 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
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 12/05/11 21:39, eric.b...@barclayscapital.com wrote: Posted this in the Google Group, but not sure if it's going through, so I apologize for the
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: 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
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 pointer
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 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
Re: can $dbh-do take a prepared statement handle?
On Fri, Jun 3, 2011 at 12:06, Jeff Macdonald macfisher...@gmail.com wrote: can $dbh-do take a prepared statement handle? No. See 'perldoc DBI'. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h 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: 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?
=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: 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: 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 br /;
}
*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()
On Jun 3, 2011, at 9:58 PM, eric.b...@barclayscapital.com
eric.b...@barclayscapital.com 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
