RE: doubt
Try delimiting each element of the in clause, i.e. ...in ('a','b')
-Original Message-
From: Agarwal, Ramakant [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 10, 2002 9:25 AM
To: '[EMAIL PROTECTED]'
Subject: RE: doubt
Hi,
I did not get any answer to my first question and asking for one more
doubt.
The problem is that I have a query some thing like this
select fields from table_name
where field_1 in set_of_values
The problem is that this query is working fine when there is only one value
in the set_of_values ,for ex. a
but if I have more than 1 value in the value set then it is not not giving
any result,for ex a,b
I tested the query using both ora perl and Perldbi but nothing is working.
Can anyone please help me out?
Thanks in advance..
P.S. Please let me know if you want any relevant details regarding this or
if the problem is not clear.
Thanks,
Ramakant
-Original Message-
From: Agarwal, Ramakant
Sent: Wednesday, September 04, 2002 7:54 PM
To: [EMAIL PROTECTED]
Subject: RE: doubt
Hi,
I have some stored procedure/function in oracle and it returns the result
through ref cursor. I want to know if we can use perl scripts to invoke this
procedure and get the result using ref cursor. Can you please help??
Thanks,
Ramakant
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free. The
sender therefore does not accept liability for any errors or omissions in
the contents of this message that arise as a result of e-mail transmission.
This message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
All e-mails at Neuberger Berman are, in accordance with Firm policy, to be
used for Neuberger Berman business purposes only. E-mails sent from or to
the Firm are subject to being reviewed by the Firm in accordance with the
Firm's procedure for the review of correspondence.
DSN-Less Connection String for Informix ODBC driver
Since I hadn't heard back from anyone, I did some more research and playing
around and got the right combination and here are results:
For DSN-Less connection string that can be used with Informix Client-SDK 2.5
ODBC driver to connect using Perl (5.005_3) on Win32, DBI, DBD::ODBC (0.28)
1. Once the Informix Client-SDK has been installed, there is a Informix
Client-SDK utility called SetNet32 that has be run to set up the proper
Informix vars, such as host, server, service, etc. for a given
server/database and then that server has to be designated as the default
server.
2. Also make sure in your winXX/system32/drivers/etc/Services file, the
proper Informix service and port no./service are set up.
If the above is done then the following should work in order to connect to
Informix using DBI and ODBC without a DSN (
my $dsn ='driver={INFORMIX 3.32 32
BIT};host=host_name;srvr=server_name;serv=service_name;pro=olsoctsp;database
=database_name;uid=id;pwd=password;';
#
# protocol name above is olsoctcp, other protocols will work as long as
supported by network
#
$dbh = DBI-connect(dbi:ODBC:$dsn, { RaiseError = 1, AutoCommit = 1});
DSN...Leave home without it!
Alex Mitsuda @ NEUBERGER BERMAN
* [EMAIL PROTECTED] * 646-497-4181
@ SECOND FOUNDATION TECH., INC.
* [EMAIL PROTECTED] * 718-686-2870
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free. The
sender therefore does not accept liability for any errors or omissions in
the contents of this message that arise as a result of e-mail transmission.
This message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
All e-mails at Neuberger Berman are, in accordance with Firm policy, to be
used for Neuberger Berman business purposes only. E-mails sent from or to
the Firm are subject to being reviewed by the Firm in accordance with the
Firm's procedure for the review of correspondence.
DBI and Informix Client-SDK 2.5 problem
Hello all, perhaps someone has come across this problem and can help me out. I'm a newbie to the Win32 environment and it's killing me.. I'm on Win32 platform, using Perl, using the Informix Client SDK 2.5 (driver INFORMIX 3.32 32 BIT). It's installed properly as I can use their logon and ping utilities to connect to Informix. On a DBI connect I'm getting a Informix ODBC Driver error : Unable to load translation DLL. I'm sure it's probably some environment setting. If someone could just point me in the right direction...thanks Alex Mitsuda @ NEUBERGER BERMAN * [EMAIL PROTECTED] * 646-497-4181 @ SECOND FOUNDATION TECH., INC. * [EMAIL PROTECTED] * 718-686-2870 This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmission. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. All e-mails at Neuberger Berman are, in accordance with Firm policy, to be used for Neuberger Berman business purposes only. E-mails sent from or to the Firm are subject to being reviewed by the Firm in accordance with the Firm's procedure for the review of correspondence.
RE: To find a just-inserted record
Need to be a bit careful though, if there are simultaneous inserts going
on @@identity is not guaranteed to give back the correct key...besides a
numeric primary key, it's always good practice to have an alternate primary
key with which you can check against...
-Original Message-
From: William R Ward [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 21, 2001 4:38 PM
To: [EMAIL PROTECTED]
Subject: Re: To find a just-inserted record
[EMAIL PROTECTED] (Chris Spurgeon) writes:
Another data point for this discussion if you're connecting to a
Microsoft Access Database via DBI, you can get the most recently created
primary key by using the @@identity value. Like this
$sth = $dbh-prepare( 'select @@identity');
$sth-execute();
I believe it's the same in Sybase and MS SQL Server.
In MySQL, there's a DBD variable you access instead of executing
another query: $sth-{insertid}.
--Bill.
--
William R Ward[EMAIL PROTECTED]
http://www.wards.net/~bill/
-
If you're not part of the solution, you're part of the precipitate.
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free. The
sender therefore does not accept liability for any errors or omissions in
the contents of this message that arise as a result of e-mail transmission.
This message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
All e-mails at Neuberger Berman are, in accordance with Firm policy, to be
used for Neuberger Berman business purposes only. E-mails sent from or to
the Firm are subject to being reviewed by the Firm in accordance with the
Firm's procedure for the review of correspondence
RE: merant / ODBC - DBI/DBD
You can do this using DBD::Sybase Library and DBI as long as the SQLServer7 has most uptodate patch, without having to use Merant/ODBC solution. Though I'm not sure how the DBD::Sybase install will go without actually having Sybase on the box... -Original Message- From: Meng Yoke [mailto:[EMAIL PROTECTED]] Sent: Sunday, November 11, 2001 10:18 AM To: [EMAIL PROTECTED] Subject: merant / ODBC - DBI/DBD Hi, MERANT / DBI/DBD / ODBC / Solaris 8 - SQL7/NT I need to use write perl (possibly DBI/DBD) in Solaris to connect to SQL7 on NT machine. Does anyone done such script before? I need to know of problem that I may be facing and possibly your-comment? Thanks. - Yoke = === Yoke Meng Keong Email : [EMAIL PROTECTED] eFax : (253) 669-6578 (US) === __ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmission. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. All e-mails at Neuberger Berman are, in accordance with Firm policy, to be used for Neuberger Berman business purposes only. E-mails sent from or to the Firm are subject to being reviewed by the Firm in accordance with the Firm's procedure for the review of correspondence.
RE: = NULL vs. IS NULL
sorry, don't have a simple explanation...some implementations of the original theory are a bit off based on DB vendor, but I will do a bit of research and get back to you... -Original Message- From: Sterin, Ilya [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 23, 2001 6:06 PM To: 'Mitsuda, Alex '; '[EMAIL PROTECTED] ' Subject: RE: = NULL vs. IS NULL Then explain assigning NULL to values in the update query and not being able to query based on NULL as for foo=NULL, but set foo=NULL is legal. Ilya -Original Message- From: Mitsuda, Alex To: [EMAIL PROTECTED] Sent: 10/23/01 4:03 PM Subject: RE: = NULL vs. IS NULL ...choosing to disagree in this case is like saying you would prefer to find oak leaves on a maple tree, unfortunately. The definition of NULL in relational databases was defined by Codd Date when they defined the theory of relational databases and the sets of data that are valid. -Original Message- From: Bart Lateur [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 23, 2001 5:57 PM To: [EMAIL PROTECTED] Subject: Re: = NULL vs. IS NULL On Tue, 23 Oct 2001 12:35:57 -0500, Stephen Clouse wrote: This is not Oracle, but ANSI-standard behavior. NULL represents the absence or non-existence of a value. A non-existent value cannot be equal to anything. So this is the correct behavior. I personally don't think DBI should muck with proper behavior. My personal opinion is to disagree. To me, NULL means empty. It is not the same as a zero length string. But empty is empty, thus NULL=NULL. Nitpicking that NULL != NULL, is only making our life harder. Last week, there was a similar discussion going on, on the Perl6 mailing lists, with regards to NaN (Not A Number). Is NaN==Nan, or NaN!=NaN? -- Bart. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmission. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. All e-mails at Neuberger Berman are, in accordance with Firm policy, to be used for Neuberger Berman business purposes only. E-mails sent from or to the Firm are subject to being reviewed by the Firm in accordance with the Firm's procedure for the review of correspondence. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmission. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. All e-mails at Neuberger Berman are, in accordance with Firm policy, to be used for Neuberger Berman business purposes only. E-mails sent from or to the Firm are subject to being reviewed by the Firm in accordance with the Firm's procedure for the review of correspondence.
RE: Warning for those using Cursors in Microsoft SqlServer with ODBC or ADO
Additionally, use SET NOCOUNT ON if you plan on using temp tables inside stored procedures! Basically what this option (NOCOUNT) does is turn off the message returned at the end of each statement that states how many rows were affected by the statement. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, June 15, 2001 11:02 AM To: [EMAIL PROTECTED] Subject: Warning for those using Cursors in Microsoft SqlServer with ODBC or ADO Hi all Just thought I'd let you know about a gotcha when using ODBC (and ADO I think) to connect to Microsoft Sqlserver. I now highly recommend having: SET NOCOUNT ON as the first statement in all your stored procedures. I had a cursor inside a stored procedure that ran correctly from isqlw but would not run correctly when called from ODBC. I thought the problem may be something to do with DBI but thankfully it is not. Unfortunately DBI does not pick up the error message (if any ) that is generated. The Cursor would fail after a fixed number of rows , any changes to the proc would seem to randomly alter number of rows before it would fail. Using the above setting stops SQL returning all the result sets that it generates for any INSERT, UPDATE,DELETE or SELECT. It is the number of rows effected by the action. eg (1 row effected) Adding the above SET statement fixed the problem. regards Tim For more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmission. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. All e-mails at Neuberger Berman are, in accordance with Firm policy, to be used for Neuberger Berman business purposes only. E-mails sent from or to the Firm are subject to being reviewed by the Firm in accordance with the Firm's procedure for the review of correspondence.
