Re: DBD::Oracle & 10.1 client
On Fri, 2005-10-21 at 20:47 +0100, Tim Bunce wrote: > > Ah, I didn't spot the attached trace. Sorry. > > OCIStmtExecute(831e534,8323594,831e5a8,0,0,0,0,0)=SUCCESS > OCIAttrGet(8323594,OCI_HTYPE_STMT,bfffe906,0,10,831e5a8)=SUCCESS > dbd_st_execute SELECT returned (SUCCESS, rpc0, fn4, out0) > dbd_st_fetch 2 fields... > OCIStmtFetch(8323594,831e5a8,1,2,0)=SUCCESS > dbih_setup_fbav for 2 fields => 0x829bfac > dbd_st_fetch 2 fields SUCCESS > 0 (rc=0): '?.' > 1 (rc=0): '51' > > Sure looks like an Oracle problem. > > Tim. Just to follow up, it was an Oracle problem, what problem I am not sure. We ended up putting a 9i client on the server, which works. The funny thing is that the 10g client that was on that server would work with another 10g Db. The only difference is the one db was on an Alpha and the other one (the one that worked) was on a Linux server. -- Scott T. Hildreth <[EMAIL PROTECTED]>
RE: Newline inserted?
Really? I use SQL*Plus in cron jobs all the time.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Monday, October 24, 2005 12:23 PM
To: Reidy, Ron; dbi-users@perl.org
Subject: RE: Newline inserted?
This runs as a CRON job loading syslog data into Oracle so SQL*Plus is
not a good answer. Thanks for help though.
-Original Message-
From: Reidy, Ron [mailto:[EMAIL PROTECTED]
Sent: Monday, October 24, 2005 11:08 AM
To: Fontenot, Ward P.; dbi-users@perl.org
Subject: RE: Newline inserted?
If your file has a '\n' in it, it cannot possibly be an issue with DBI
or Oracle v anything.
Are you processing individual SQL statements (does your file contain SQL
insert statements)? If so, DBI is not your best bet to do this. I
would rethink this and:
a. Use SQL*Plus to load the file:
sqlplus -L /nolog mailto:[EMAIL PROTECTED]
Sent: Monday, October 24, 2005 12:01 PM
To: dbi-users@perl.org
Subject: Newline inserted?
I have the following sql insert statement in a file:
INSERT INTO message(FULLDATE,HOSTNAME,FACILITY,PRIORITY,MESSAGE,SHA1)
VALUES('2005-Oct-18 11:53:21','pkitest.wellsfargo.com','auth
','info','su(pam_unix)[3638]: session opened for user oracle by
root(uid=0)','H4vgmf+OJsT99kCfQuIpALY7k9k=');
When I attempt to load this file into Oracle 10g using the DBI I get the
following error:
DBD::Oracle::st execute failed: ORA-00911: invalid character (DBD ERROR:
error possibly near <*> indicator at char 238 in 'INSERT INTO
message(FULLDATE,HOSTNAME,FACILITY,PRIORITY,MESSAGE,SHA1)
VALUES('2005-Oct-18
11:53:21','pkitest.wellsfargo.com','auth','info','su(pam_unix)[3638]:
session opened for user oracle by
root(uid=0)','H4vgmf+OJsT99kCfQuIpALY7k9k=')<*>;')
This is the code that loads this file:
while () {
chomp;
$sql = qq{$_};
$sth = $dbh->prepare($sql); # Should these be outside the loop?
$sth->execute();
}
Od -cx FILENAME shows a "\n" character at the <*> point in the above
file. VI -b does not. Is this a known issue with DBI and 10g or am I
overlooking something?
Paul Fontenot
WFS - CAST Operations
Email: [EMAIL PROTECTED]
Phone: (480) 437-7795
This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation.
This electronic message transmission is a PRIVATE communication which
contains information which may be confidential or privileged. The
information is intended
to be for the use of the individual or entity named above. If you are
not the
intended recipient, please be aware that any disclosure, copying,
distribution
or use of the contents of this information is prohibited. Please notify
the sender of the delivery error by replying to this message, or notify
us by telephone (877-633-2436, ext. 0), and then delete it from your
system.
This electronic message transmission is a PRIVATE communication which contains
information which may be confidential or privileged. The information is
intended
to be for the use of the individual or entity named above. If you are not the
intended recipient, please be aware that any disclosure, copying, distribution
or use of the contents of this information is prohibited. Please notify the
sender of the delivery error by replying to this message, or notify us by
telephone (877-633-2436, ext. 0), and then delete it from your system.
RE: Remote Login, using dbi:ODBC
If you really need to log into Access remotely, check out DBD::Proxy on CPAN.
Ted
> -Original Message-
> From: Jeff Urlwin [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 24, 2005 12:22 PM
> To: [EMAIL PROTECTED]; dbi-users@perl.org
> Subject: RE: Remote Login, using dbi:ODBC
>
>
> This really isn't a perl/dbi issue. If it's an MS access
> database, you
> need to be able to access the MDB file itself. Thus, there is no
> server/port, etc.
>
> Jeff
>
>
> -Original Message-
> From: Richard [mailto:[EMAIL PROTECTED]
> Sent: Sunday, October 23, 2005 2:33 AM
> To: dbi-users@perl.org
> Subject: Remote Login, using dbi:ODBC
> Importance: High
>
> I login to my remote mysql databases, using perl, this way:
>
>
>
>
>
>
>
> sub ConnectToDB
>
> {
>
> my $host_name = "01.002.003.04";# Ip Address Here
>
> my $db_name = "DataBaseName"; # Database Name to
> connect to
>
> my $dsn = "DBI:mysql:host=$host_name;database=$db_name";
>
> return (DBI->connect ($dsn, "usernameHere",
> "PasswordHere",
>
>
> {PrintError => 0, RaiseError => 1}));
>
> }
>
>
>
> So, to connect to a Remote Access Database, can I use this:
>
>
>
>
>
> sub ConnectToDB
>
> {
>
> my $host_name = "002.003.004.05";
>
> my $db_name = "DBName";
>
> my $dsn =
> "dbi:ODBC:Clients:host=$host_name;database=$db_name";
>
> return (DBI->connect ($dsn, "UserNameHere",
> "PassWordHere")); #
> Clients being the name I set in the Windows Data Sources (ODBC)
>
> }
>
>
>
>
>
> Is that how I would connect to this database?
>
>
>
> I would appreciate any help you could give me.
>
>
>
> Thanks!
>
> Richard
>
>
>
>
Re: ANNOUNCE: MySQL 5.0 now final/stable/GA
Hi Darren:
I think an update about the recommended minimum database version
levels for your access modules is on-topic for this mailing list, but
suspect that product advertisements are probably off-topic -- personal
opinion, maybe, but I don't want to see this list become a dumping
ground for the latest releases and associated features of Oracle,
Postgres, Informix IDS, DB2, SQL Server, etc.
Dan
On 10/24/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
> For those of you that use MySQL, this should be
> welcome news, that version 5.0.x is now
> officially stable, at 5.0.15.
>
> Speaking just personally, the recommended minimum
> versions of certain database products to use with
> my upcoming rewritten database access modules are
> the following; they are all stable, and what I
> will be testing with:
>
> - SQLite 3.x (3.2.7+)
> - MySQL 5.x (5.0.15+)
> - PostgreSQL 8.x (8.0.4+)
>
> I will also support several previous major
> versions of all 3, but at lower priority, based
> on user demand, partly to assist with upwards
> migrations.
>
> -- Darren Duncan
>
> ---
>
> Date: Mon, 24 Oct 2005 15:40:43 +0300
> From: Kaj Arnö <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Announcing MySQL 5.0
>
> Dear user of MySQL,
>
> It is my pleasure to announce the production release of MySQL 5.0, which
> is hereby GA (Generally Available). Since my announcement of the Release
> Candidate less than a month ago, no bugs have been reported that require
> a second Release Candidate. This, combined with the feedback from over
> two million downloads of MySQL 5.0 during its beta phase, give us the
> confidence to give MySQL 5.0 the status of Current Production Release, or GA.
>
> In the Release Candidate announcement less than a
> month ago, I described MySQL 5.0 as "the most
> important release in MySQL's history", and that
> is certainly the case. Thus, I encourage you all
> to:
>
> - get your own copy at
>http://dev.mysql.com/downloads/mysql/5.0.html
>
> - do all of your new database development using MySQL 5.0
>
> - upgrade your current MySQL environments to MySQL 5.0, as soon as
>you've properly verified your production applications against it
>(be sure to take a full backup of your data before upgrading, study
>the relevant documentation, and if you have a MySQL Network support
>contract, consult first with the MySQL Support Team)
>
> Let me also underline that we continue to offer some earlier versions of
> MySQL Server for download. However, you should expect maintenance
> releases for earlier versions only in limited form:
>
> - for MySQL 4.1, only when serious bugs affecting significant user
>groups are reported
>
> - for MySQL 4.0, only when security bugs are reported
>
> MySQL 5.0 is the most ambitious release to date for MySQL AB. We have
> added functionality that our users have requested from us over many
> years. However, everything we do at MySQL centers around our three
> priorities of Performance, Reliability, and Ease of Use. MySQL 5.0 is
> certainly true to these company-wide values.
>
> Key new features of MySQL 5.0 come in three groups:
>
> a) ANSI SQL standard features formerly unknown to MySQL
>
> b) ANSI SQL standard compliance of existing MySQL features
>
> c) New MySQL Storage Engines, Tools and Extensions
>
> The new ANSI SQL features include:
>
> - Views (both read-only and updatable views)
>
> - Stored Procedures and Stored Functions, using the SQL:2003 syntax,
>which is also used by IBM's DB2
>
> - Triggers (row-level)
>
> - Server-side cursors (read-only, non-scrolling)
>
> Implementing ANSI SQL standard ways of using existing MySQL features
> means there will be fewer unpleasant surprises ("gotchas") for those
> migrating to MySQL from other database systems:
>
> - Strict Mode: MySQL 5.0 adds a mode that complies with standard SQL
>in a number of areas in which earlier versions did not; we now do
>strict data type checking and issue errors for all invalid dates,
>numbers and strings as expected
>
> - INFORMATION_SCHEMA: An ANSI SQL-compliant set of tables that
>provide database metadata, in parallel with the MySQL-specific
>SHOW commands
>
> - Precision Math: A new library for fixed-point arithmetic, giving
>high accuracy for financial and mathematical operations
>
> - VARCHAR Data Type: The maximum effective length of a VARCHAR column
>has increased to 65,532 bytes; also, stripping of trailing whitespace
>no longer occurs
>
> New MySQL Storage Engines, Tools and Extensions are:
>
> - XA Distributed Transactions
>
> - ARCHIVE Storage Engine for storing large amounts of data without
>indexes in a very small footprint, intended for historical data that
>may be needed for future audit compliance (Sarbanes Oxley or
>otherwise)
>
> - FEDERATED Storage Engine for accessing data ín tables of remote
>databases rather than in local tables (only in MAX version)
>
> - Instance Manager: a tool to start a
RE: Remote Login, using dbi:ODBC
This really isn't a perl/dbi issue. If it's an MS access database, you
need to be able to access the MDB file itself. Thus, there is no
server/port, etc.
Jeff
-Original Message-
From: Richard [mailto:[EMAIL PROTECTED]
Sent: Sunday, October 23, 2005 2:33 AM
To: dbi-users@perl.org
Subject: Remote Login, using dbi:ODBC
Importance: High
I login to my remote mysql databases, using perl, this way:
sub ConnectToDB
{
my $host_name = "01.002.003.04";# Ip Address Here
my $db_name = "DataBaseName"; # Database Name to connect to
my $dsn = "DBI:mysql:host=$host_name;database=$db_name";
return (DBI->connect ($dsn, "usernameHere", "PasswordHere",
{PrintError => 0, RaiseError => 1}));
}
So, to connect to a Remote Access Database, can I use this:
sub ConnectToDB
{
my $host_name = "002.003.004.05";
my $db_name = "DBName";
my $dsn =
"dbi:ODBC:Clients:host=$host_name;database=$db_name";
return (DBI->connect ($dsn, "UserNameHere",
"PassWordHere")); #
Clients being the name I set in the Windows Data Sources (ODBC)
}
Is that how I would connect to this database?
I would appreciate any help you could give me.
Thanks!
Richard
