Re: DBI with ORACLE encryption

[moved to [EMAIL PROTECTED] I can't help unless you, or someone, can indicate what OCI calls the driver needs to make (assuming that is the problem). Tim. On Wed, Mar 10, 2004 at 02:05:49PM +0530, [EMAIL PROTECTED] wrote: Hi, We are using Oracle version 8.1.7.4 as the database running on

Re: Span a database transaction across multiple CGI scripts

Hello, Sagara Wijetunga [EMAIL PROTECTED] wrote: Is it possible to span a database transaction across multiple CGI scripts? That is, start transaction and lock some records in one CGI script and update and commit in another CGI script. RJK One possible approach is to set up a separate

RE: Trying to make DBI work for me

We ran into this same problem on multiple machines. The solution that worked for us was to completely remove the perl installation directory after uninstalling it. For whatever reason the uninstall process is leaving something behind that conflicts with the new installation. Everything worked

RE: Trying to make DBI work for me

I did this very thing yesterday (uninstalled 5.6, installed 5.8, and then reloaded the DBI/DBD stuff), and you're right--it worked. Thanks to everyone who responded. Laurie -Original Message- From: Andrews, Mark [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 10, 2004 7:56 AM To:

varchar2 4000

Is anyone having trouble inserting or updating 4000 characters in oracle 9i using perl?

RE: varchar2 4000

I had no problems inserting a string of 4000 numbers or characters into a varchar2(4000). -Original Message- From: Bretz, Ellen [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 10, 2004 10:56 AM To: [EMAIL PROTECTED] Subject: varchar2 4000 Is anyone having trouble inserting or updating

Re: Span a database transaction across multiple CGI scripts

I was thinking of a different approach to doing it off to the side, such as using a separate (buffer) table where the processing is done, then moving it in to your primary table at the end. This provides for a bit more auditting than the hidden fields do, but is more expensive. If you don't

DBD::mysql iThreads

I have a chain of queries on which I'm computing. Each query has an overhead of 15-20 seconds (since the results are sorted by the server). Now it takes me a good 30 seconds to process the results of each query, so I'd really like to be executing the next query while processing the results of

make DBD-Oracle-1.15 problem

Hi! Per your suggestion I have used: -lcl -lpthread +z == it's warning that there is +Z already Same errors I got when used: perl Makefile.PL -l -g -v == see log at the end I have tried to run use makefile from README.hpux/APPENDIX A,

Compiling invalid objects using perl DBI

DBD::Oracle::db do failed: ORA-24344: success with compilation error (DBD SUCCESS_WITH_INFO: error possibly near * indicator at char 1326 in 'alter VIEW APT_V53R2.V_NOP_PRESUM compile) [for Statement alter VIEW APT_V53R2.V_NOP_PRESUM compile] at D:/main_source/olf/bin/recompile line 113, DATA line

Avoiding coding username/password directly into perl script

Hi there, I figured this would be a pretty common problem, but I didn't see anything in the FAQ or docs. We've got a script that uses DBI to connect to SQL Server. There is a system DSN set up and this already has the username and password. So do we really need to pass them again, as shown

RE: Avoiding coding username/password directly into perl script

well, if your database requires a username/password, then you can't just pass it the path (DSN). Not even sure how you expect anyone to do that. I believe certain ODBC clients might have the capability to embed that either inside the DSN and/or somewhere else on the system, so that when a

Re: Avoiding coding username/password directly into perl script

Hello Try passing them in as blanks. my $db = DBI-connect(dbi:ODBC:$dsn, '', ''); Peter News Reader wrote: Hi there, I figured this would be a pretty common problem, but I didn't see anything in the FAQ or docs. We've got a script that uses DBI to connect to SQL Server. There is a system

Re: Avoiding coding username/password directly into perl script

You _do_ need to include the user name and password in the DBI connect statement, but the way to make it more secure is to not hardcode those in your scripts - create a Perl module in which you place variables that _do_ contain the hardcoded values, but place that perl module in a secure place on

RE: Avoiding coding username/password directly into perl script

If the user\pass is already in the DSN you should be able to just... my $db = DBI-connect(dbi:ODBC:$dsn,,); -Original Message- From: Sterin, Ilya (I.) [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 10, 2004 12:43 PM To: [EMAIL PROTECTED] Subject: RE: Avoiding coding username/password

Re: TeraNews: RE: Avoiding coding username/password directly into perl script

On Wed, 10 Mar 2004 12:50:59 -0600, Brad Fike [EMAIL PROTECTED] said: Thanks for the ideas. I did try entering them in as blanks, but I still got this error: DBI-connect(BWEB) failed: [Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user '(null)'. Reason: Not associated with a

Re: Avoiding coding username/password directly into perl script

[EMAIL PROTECTED] wrote: Hi there, I figured this would be a pretty common problem, but I didn't see anything in the FAQ or docs. We've got a script that uses DBI to connect to SQL Server. There is a system DSN set up and this already has the username and password. So do we really need to pass

Re: TeraNews: RE: Avoiding coding username/password directly into perl script

I see in 'perldoc DBD::ODBC' that the user id and password _is_ required when using DBD::ODBC to connect to an ODBC data source. I looked up a few of my ODBC 'System' data sources, and although they do contain the user id, they do _NOT_ contain the password. So I'll stick with my previous

Re: Compiling invalid objects using perl DBI

On Wed, Mar 10, 2004 at 01:43:43PM -0500, Veera Prasad wrote: DBD::Oracle::db do failed: ORA-24344: success with compilation error (DBD SUCCESS_WITH_INFO: error possibly near * indicator at char 1326 in 'alter VIEW APT_V53R2.V_NOP_PRESUM compile) [for Statement alter VIEW

DBD::Oracle to Oracle9i problem with Database link

Hello Everyone, I have Perl 5.8.1 on Sun Solaris 9 and it has Oracle 9.2I have build latest DBI(v1.41) and DBD::Oracle(v1.15) from tarred files, and I did not see any major problems on those builds...I wrote a simple script(select stament) to test Database and it ran fine. But when I try to

Re: DBD::Oracle to Oracle9i problem with Database link

Shail, We had problems using database links with 9.2.0.1.0 and 9.2.0.2.0, after going to 9.2.0.3.0 the problems went away. I should mention that this was in the context of links used outside perl/DBI, and were rather aleatory. Rafael Caceres On Wed, 2004-03-10 at 15:49, Shail Dahal wrote:

Re: DBI with ORACLE encryption

I assume you have enabled Oracle Advanced Security. There are client and server specific settings as well as the CRYPTO SEED which must be the same on both. I'm sure you can find this on google or the free Oracle forums. Hope it helps. Kevin Tim Bunce wrote: [moved to [EMAIL PROTECTED] I

FW: CPAN Upload: J/JU/JURL/DBD-ODBC-1.09.tar.gz

Sorry about that folks. Forgot about adding the dbivport.h to the Manifest. Should avoid anyone with build errors. Regards, Jeff The uploaded file DBD-ODBC-1.09.tar.gz has entered CPAN as file: $CPAN/authors/id/J/JU/JURL/DBD-ODBC-1.09.tar.gz size: 93117 bytes md5: