On 05/04/2005 02:40 PM, Denesa K Shaw said:
Any Ideas on why I'm getting this error? It appears not to like my date
that I'm passing to it. I printed the date to a log and it looks ok, any
ideas?
Error:
DBI::st=HASH(0x20391b00)->bind_param(...): attribute parameter
'TO_DATE('01/02/200','mm/dd/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I am running a postgresql database and am finding that DBI is returning
> the wrong data type for the postgresql DATE type.
> ...
> The problem lies with the birthdate column. In postgresql, the data
> type is 'date'. When I run the above code it
Any Ideas on why I'm getting this error? It appears not to like my date
that I'm passing to it. I printed the date to a log and it looks ok, any
ideas?
Thanks!
Error:
DBI::st=HASH(0x20391b00)->bind_param(...): attribute parameter
'TO_DATE('01/02/2
00','mm/dd/ hh24:mi:ss')' is not a hash r
I have proceeded further (Thanks Tom). I had a blank local file
(~/.odbc.ini) and I removed it. Now I'm getting a "Connection refused"
error, so at least it's trying to talk to the server.
Any thoughts?
Here is the output from CPAN's 'install DBD::ODBC' command:
cpan> install DBD::ODBC
CPAN: St
On Wed, 2005-05-04 at 19:16, Mohankumar wrote:
> Hi Folks,
> I am using the perl version 5.005_02 built for MSWin32-x86 and sybase
> 9.0.0. I have a DB and a table. I have used bigint as datatype for some
> columns in a table. The bigint values are stored correctly in database. While
> I tr
Bump
Does anybody have any ideas on this one? It seems like a pretty serious
issue.
Collin
Collin Peters wrote:
I am running a postgresql database and am finding that DBI is returning
the wrong data type for the postgresql DATE type. Here is some example
code:
===
Hi Folks,
I am using the perl version 5.005_02 built for MSWin32-x86 and sybase
9.0.0. I have a DB and a table. I have used bigint as datatype for some columns
in a table. The bigint values are stored correctly in database. While I trying
to fetch the columns from the table, the columns whi
As Tim said, look at the RowCacheSize, I have seen big speed gains
by increasing this attribute.
On Wed, 2005-05-04 at 10:38 +0100, Tim wrote:
> On Wed, May 04, 2005 at 02:18:02AM -0400, Steve Sapovits wrote:
> >
> > >I meant to also note that the job in question is all SELECTs --
> > >it only pu
On 05/03/2005 11:42 AM, [EMAIL PROTECTED] said:
/usr/ucb/cc: language optional software package not installed
*** Error code 1
make: Fatal error: Command failed for target `Perl.o'
What language optional software package (name) does the error message
refer to?
The one that includes the same compil
Scott T. Hildreth wrote:
As Tim said, look at the RowCacheSize, I have seen big speed gains
by increasing this attribute.
We do use that and I have also seen decent (maybe not big) gains.
The big problem we have with it is maintaining a good setting as
our data grows, since we usually set it to a n
Then post the code to the list, and let's see if someone can spot what's
going on.
Jeff Seger
Fairchild Semiconductor
[EMAIL PROTECTED]
"Hawkes, Richard" <[EMAIL PROTECTED]>
05/04/2005 09:01 AM
To: Jeffrey Seger/Corporat
Are you running with the same user in both your perl script and in
sql*plus? Have you run the query successfully in sql*plus across the link
using the same user?
Jeff Seger
Fairchild Semiconductor
[EMAIL PROTECTED]
"Hawkes, Richard"
does it reproduce in sql*plus?
ORA-3113 quite often means call Oracle support.
>From asktom.oracle.com:
The underlying cause of a 3113 can be diagnosed typically by:
o inspecting the alert log on the server. There should be a message in there
typically that tells of the error occuring and
On Wed, May 04, 2005 at 02:18:02AM -0400, Steve Sapovits wrote:
>
> >I meant to also note that the job in question is all SELECTs --
> >it only pulls data and does not update any tables. If the
> >"almost there" is known to cover SELECTs that would be good to
> >know.
>
> I did some reading and
Hi Jeffrey, thanks for your help. I have added those parameters, but
unfortunately it doesn't seem to make a lot of difference. The errors are now
just appearing earlier:
DBD::Oracle::st execute failed: ORA-03113: end-of-file on communication channel
(DBD ERROR: OCIStmtExecute) at ./query_db2.cg
On Tue, May 03, 2005 at 04:28:10PM -0700, Job Miller wrote:
> the lack of it really limits perl's utility for any serious data loading
> operations that require performance. if you look at the extended sql trace
> of a:
>
> parse
> loop
> execute(x)
> end loop;
>
> you will see that it using
16 matches
Mail list logo
