In case anyone cares.
It appears the threaded version of Perl 5.8.0 on OSX is incompatible with
DBI. This really bites since you need the threaded version for Apache
2.0.43 and mod_perl 1.99_07. So, on OSX, you are probably better off
using FastCGI or, I hate to say, Java Servlets/JSP for
... that version I do not believe has the problems that Perl5.8.0
has (however, it has a whole slew of other problems... this is why I am
upgrading).
Thanks,
Curt
On Sat, 15 Feb 2003, David Wheeler wrote:
On Saturday, February 15, 2003, at 09:57 AM, Curt Russell Crandall
wrote:
It appears
these problems.
On Sat, 15 Feb 2003, David Wheeler wrote:
On Saturday, February 15, 2003, at 11:13 AM, Curt Russell Crandall
wrote:
I would assume that if you were using OSX 10.1 that you were using
Perl5.6.0... that version I do not believe has the problems that
Perl5.8.0
has (however, it has
, David Wheeler wrote:
On Monday, February 10, 2003, at 09:06 PM, Curt Russell Crandall wrote:
I reran the install and before I could complete the make step, I
received
the error:
[CurtsiMac:~ccrandal/DBI-1.32] root# make
cc -c -pipe -fno-common -no-cpp-precomp -fno-strict-aliasing -O3
I reran the install and before I could complete the make step, I received
the error:
[CurtsiMac:~ccrandal/DBI-1.32] root# make
cc -c -pipe -fno-common -no-cpp-precomp -fno-strict-aliasing -O3
-DVERSION=\1.32\ -DXS_VERSION=\1.32\
-I/Library/Perl/darwin-thread-multi/CORE -Wall -Wno-comment Perl.c
The *.mdb file IS the Access database. I've tried a couple of ways to
read it on a UNIX system and nothing worked. Your best bet is to set up a
similar scheme on a database that sits on your Linux box (i.e. Postgres,
MySQL, etc). On the Windows machine, load Perl (like ActiveState
Perl) with
Install DBD::Sybase and then
perldoc DBD::Sybase
Also, the Programming the Perl DBI is a good reference book to have.
HTH,
Curt
On Tue, 20 Nov 2001, Mcgregory Pinto wrote:
Hy all
I´m a beginer.
I´m looking for any information about DBI::Sybase.
Where i can get it ??
Thanks.
Gregory
Maybe I've missed something... but I'd recommend not using a tarball
directly and just use the CPAN module to install it:
perl -MCPAN -e install 'DBI'
perl -MCPAN -e install 'DBD::Sybase'
perl -MCPAN -e install 'DBD::Oracle'
assuming you have a standard setup on your box, you can probably just
We don't set INFORMIXDIR in the scripts, the system is set up so all
accounts (including web, the account that owns all the web content and
scripts) have $INFORMIXDIR set to /usr/informix.
What is odd is that for the SAME script, it will display $DBI::errstr
correctly once, and then the next
error codes, so it only reads from
that file the first time?
What is CSDK? Since I do not know what it is, I'm not sure what version
it would be.
Thanks
--Curt
On Thu, 16 Aug 2001, Gary Armstrong wrote:
Curt Russell Crandall wrote:
We don't set INFORMIXDIR in the scripts, the system is set up
Forgot this in the last reply... it's the code I'm using to examine this
problem. Basically, it provides a text box for you to enter 1 SQL
statement. If executed successfully, it prints the results otherwise it
prints the error. Ignore the Javascript, it's not completed, but it's
meant to
Thanks for the information. I'm not authorized to rebuild DBD::Informix
on these systems nor do I know when or how DBD::Informix was built last
time. I'll forward your advice to the senior developer here.
It's still a little confusing as to how I'll get the correct errstr the
first time, but
I'm just trying to gather info... I'll let the senior developer worry
about reinstalls and stuff... less for me to worry about. So, I'm not
upset at all about not having authority to reinstall things. Actually,
there's nothing stopping me since I'm root... but I don't want to make the
boss mad.
We've been noticing that often times DBD::Informix is not returning the
whole error message generated by the database. For example, I received
the following string in response to a char to numeric conversion error:
SQL:-1213:
However in the Apache error_log, I get:
FastCGI: server
I have a FCGI script that lets you enter an sql statement in a textbox and
on submit the statement is submitted to the database. If it is a select
statement, a table with the results is displayed. If it is not a select
statement, the program simply prints an error that fetch* didn't work.
I'd
That's kind of like the workaround I have in now, but it's not the
solution I really want... I would like to display verbatim the return
message from Informix since there will be some commands issued where
looking at the return value for the number of rows updated will be
insufficient.
Thanks,
The perldoc I have does not refer to a sqlda structure, however it briefly
talks about a sqlca structure... but I am unable to find the specific
information I need. I'll have to track down the Informix manuals and look
at this structure in there.
Thanks,
Curt
On Tue, 3 Jul 2001, Wilson, Doug
You will get this if you use the older DBD::Sybase. I struggled with this
stuff and made ugly workarounds just get stuff undef through a placeholder
with DBD::Sybase 0.21. Either switch to 0.91 or check for an undef value
and do a $dbh-quote() on it... unfortunately, you won't be able to use
I have a program that reads a file, and tries to process each line and
insert the results into a database table. If the processing fails, the
line is written to a reject file where it is corrected and reprocessed.
In reject processing mode, I open the reject table, read a line, process
it and
Sorry about that, I didn't mean to send this since midway through writing
this I figured it out for myself.
--Curt
On Fri, 29 Jun 2001, Curt Russell Crandall wrote:
I have a program that reads a file, and tries to process each line and
insert the results into a database table
I'm getting the error:
DBI::db=HASH(0xf0130)-disconnect invalidates 1 active statement handle
(either destroy statement handles or call finish on them before
disconnecting)...
What's interesting is the dbh handle has AutoCommit enabled and the lone
sth handle on that dbh is an insert... so I do
I'm having a problem with my program having its memory usage go out of
control. I'm working on Solairs 2.5.1 and 2.6 with several Perl builds:
Perl 5.00404 w/ DBI 1.13 DBD::Sybase 0.21
Perl 5.00404 w/ DBI 1.14 DBD::Sybase 0.91
Perl 5.6.0 w/ DBI 1.14 DBD::Sybase 0.91
My program is
So, should I have a separate DB handle for each statement that does
something other than selects? In the instances where the program does not
prepare this statement handle, there are still 8 or 9 other statements on
a single DB handle all of which do nothing but select queries. The memory
usage
I personally have not seen blanks come back with any of my columns unless
someone accidentally entered a whitespace character in a varchar
field. ChopBlanks=1 should remove all trailing whitespace from CHAR
fields only. If you want trailing whitespace removed from VARCHAR or
other datatypes
I have been having problems posting. The mail often bounces back to me,
yet I can receive mail from the list and can mail individuals when
replying to a post. The return message was saying that my account wasn't
be recognized, or something, by the mailing list server. I also received
a message
I didn't have an Informix DB available at the time, but yes it does return
a list of dbs with data_sources... however, Sybase does not as well as
many others.
On Thu, 7 Jun 2001, Jonathan Leffler wrote:
Curt Russell Crandall wrote:
Is the DBI-data_sources method the only facility available
As my inclusion of the previous message implies
I prefer to have not have messages trimmed on occassion... many times the
thread goes over several days and either I don't want to search for the
original message, or have already deleted the original message, or don't
have access to the
I have been using Class::Struct a lot recently and instantiating an array
object with it. You can also use a hash if you wish. This type of object
gives you a C-like structure that you can manipulate as either an array
(hash) or as a regular object using automatically generated
accessor/mutator
Is the DBI-data_sources method the only facility available in the DBI to
get a list of databases on a server? I'm trying to build a Perl/Tk
application that would give me an interface similar to say RapidSQL where
I can have a frame containing a list of all the databases on a
server... by
Instead of fetching again, setup a hash of hashes and populate it on the
first fetch... then it's right there for you the second time
around... depending on the amount of data and how many times you need to
use the same data set, it could save you more time than reexecuting and
refetching.
2) documentation (saves me explaining PHP AND Perl:DBI in the
emergency documentation should I keel over and die tomorrow and take
the Perl:DBI knowledge with me. like it or not, not many do the Perl
thing any more)
Huh? Are you just talking about at your own shop... I know very few
There's a couple of things I'm having a proble with when trying to use
dbish. First, I want to turn autocommit off. So, according to the
perldoc on DBI::Shell, I'm supposed to type /option autocommit=0, but when
I do I get the message:
Unknown or ambiguous option name 'autocommit'
I do see an
I don't think that'll work with dbish. Thanks anyway.
On Wed, 9 May 2001, Jones Robert Contr 81 CS/SCK wrote:
Try ...
$dbh-{AutoCommit} = 0;
-Original Message-
From: Curt Russell Crandall [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 09, 2001 1:57 PM
To: [EMAIL
Yes, I totally forgot about that... seems like you just mentioned that to
me not too long ago. I guess I forgot since I can't use placeholders in
my code because Sybase won't allow it with stored procs.
Sorry 'bout that.
On Tue, 8 May 2001, Ronald J Kimball wrote:
On Tue, May 08, 2001 at
I'm royally confused right now. This is something I've looked at on and
off but never followed through with and eventually would always forget
about.
I have several objects that have been created using Class::Struct. The
structure is filled by splitting a tab delimited record and feeding that
I'm getting conversion errors (VARCHAR to [SMALL]DATETIME) on an
insert. I have a structure that contains a list of params that need to be
inserted into a db table. Prior to insertion, I make sure that undef
values are treated as SQL NULLs:
for (my $i = 0; $i = $#array; $i++)
{
if
Correction, those dates I was sending are OK I mistakenly sent the
reference to them instead of the value.
However, the value NULL still doesn't work. In one case, I'm getting
the value straight from an SQL query... so it's actually undef... then I
quote() it which is supposed to properly
I need to insert and then update an entry in a table using 2 stored procs
that I am not authorized to alter. The first stored proc checks to see if
I can insert a row and if so it returns the row:
$cmd = 'exec sp_1 ...';
$sth-prepare($cmd);
$sth-execute();
while (@row =
Sorry, I reread Cheetah and DBD::Sybase perldoc and found the
_date_fmt() method. That should
work for me. Thanks anyway.
On Fri, 27 Apr 2001, Curt Russell Crandall wrote:
I need to insert and then update an entry in a table using 2 stored procs
that I am not authorized to alter
I'm rewriting a piece of C code that uses the OpenClient libraries to set
a row in a process table under certain circumstances. The chunk of Perl
code that handles this is:
package init_process;
...
my $cmd = exec sales2..sa_initprocess , $dbh-quote($item_src) . ,
. $proc_id;
my $sth =
Totally missed that first one. I guess I'll have to wrap it in a block
and set $^W = 0. I'll give the {syb_do_proc_status} =1 a try.
Thank you
You have two entries in @row that are undef (i.e. - they are NULL in
the result set).
/tmp/xxx.tmp::EXTtranldr::Apr 25 2001
Don't use BEGIN or END as subroutine names since they have special meaning
in Perl. BEGIN blocks are executed at compile time while END blocks are
always executed at program termination (unless a kill signal or something
similar is sent by the OS). Try using a different name for your
What distribution of Perl are you using. If it is not ActiveState, then
most likely the correct way to install your module would be to use the
CPAN module. You can do a perldoc on CPAN for instructions.
--Curt
On Mon, 9 Apr 2001, Reuss, Bob wrote:
Ok, I followd the docs, but ran into a new
Can't do it... the Sybase driver does not allow placeholders in a prepare
of a stored proc. I spent the better part of a day trying to figure out
why my code wasn't working when doing something similar until I read
Cheetah's section on DBD::Sybase.
--Curt
On Mon, 9 Apr 2001, Bruce Hodge wrote:
Ooops, I thought you were using the DBD::Sybase driver. Sorry.
On Mon, 9 Apr 2001, Bruce Hodge wrote:
I am using DBD::ODBC drivers to connect to a Sybase 11.5 database. I have
migrated a bunch of procedures from Oracle 8i that use output parameters to
return data. I was migrating an
Yes, you can set LD_LIBRARY_PATH within the script and it should pick
up the correct path. It is standard with
all of the DBI scripts accessing Sybase in our shop... normally the path
is in an ini file, the ini file is read and the ENV variable set. We do
this since the same account may be
If Perl DBI is saying it can't find disconnect, then I would think either
$dbh somehow gets undef'd or maybe your disconnect method is
missing. I've run into this before where my disconnect method was
"missing". It may be you just need to reinstall DBI, which is what my
sysadmin did. Why
wrote:
On Fri, Apr 06, 2001 at 02:26:31PM -0400, Curt Russell Crandall wrote:
If Perl DBI is saying it can't find disconnect, then I would think either
Perl is saying that it can't find the disconnect method in the DBI::st
package. That's the statement handle package. The disconnect
t;,
"x");
$sql = _ENDSQL;
Exec Subscribe_InsertPlan 13200,136,6,11,"04/06/2001"
_ENDSQL
$sth = $dbh-prepare($sql);
$sth-execute;
$dbh-trace(9);
$dbh-disconnect() or die("$DBI::errstr $DBI::err\n");
- Original Message -
From: "Curt Ru
Why not try DBD::Sybase if you have the db libraries for M$SQL on the
machine where your perl app is running? DBD::Sybase will run with both
Sybase and M$SQL. Sorry that doesn't really answer your question about
ODBC, but if you aren't tied to ODBC, the other driver should work for
you.
Good
Hi,
I'm having problems opening a db connection to Sybase using dbish. The
perldoc says to use the syntax:
dbi:Sybase:server=X [user [password]]
So, I executed dbish and did the following
Available DBI drivers:
1: dbi:ADO
2: dbi:ExampleP
3: dbi:Oracle
4: dbi:Proxy
5: dbi:Sybase
Enter
Bingo! I just assumed I could use the same syntax at the dbish DSN
prompt. But it works fine if I use that syntax when invoking dbish.
thanks
--Curt
On Thu, 29 Mar 2001, Michael Peppler wrote:
Curt Russell Crandall writes:
Hi,
I'm having problems opening a db connection
I kept looking and the combination of parameters passed to the select that
seems to hang ($sth3) ends up returning NULL when I run it against the
development db. Using
declare @date datetime
select @date = max(date)
from dbo.table3
where a = '020'
and b = '451'
select @date
I've now been
I think you can use h2ph to convert the header file into something that
perl can use. There's several different ways to mix Perl with C/C++. You
can use one of the embed modules, XS, inline.pm, etc. Look at the Perl
perldoc for a list of appropriate documents on embedding/extending
Perl. If
I could not read the attachment with my mail reader. Can you tell me what
C compiler you are using? Are you using the Perl interpreter supplied by
Sun? If you are, reinstall Perl using the gcc compiler. Then try
installing DBI and DBD* also using gcc. Sun's Perl and C compiler spell
disaster
.
On Wed, 28 Mar 2001, Alexander Farber (EED) wrote:
Hi Curt,
Curt Russell Crandall wrote:
I ran into a similar problem with Sybase. I had a statement prepared
using placeholders (a select statement) and I had to loop several times as
I processed transactions and each time through the loop
On Wed, 28 Mar 2001, Alexander Farber (EED) wrote:
Curt Russell Crandall wrote:
No that wasn't the case here. Each select only produces 1 result row.
Are you really sure it was 1 row?
That has been verified. It is a small table containing only 7
rows... for now.
So, I just did
First of all, I'm not an expert on PHP. But, I believe you
cpan has modules like Mason that could give you what you want
w/o messing with PHP. Actually, I'm not real
big on mixing presentation layers with code and you might consider using
mod_perl or FastCGI instead. That being said, why do
Phil,
I ran into a similar problem with Sybase. I had a statement prepared
using placeholders (a select statement) and I had to loop several times as
I processed transactions and each time through the loop I had to execute
the prepared statement. Perl and/or Sybase complained that I needed
Can you send a chunk of code so we can see what you are trying to do? In
the meantime, look in Camel III Chapter 16 (Interprocess
Communication) and perlipc perldoc for examples of correct forking. Also,
there are some examples in chapters 16 17 in the Perl Cookbook of
forking child processes.
This may be more of a general Perl question than a DBI one, but since DBI
is involved, I thought I'd ask anyway.
I create a database handle called $dbh_sale. I want to ensure that this
handle is destroyed at the end of the program... so, I wrote up this chunk
of code
END
{
I'm having a problem where my intention is to insert a NULL value into a
nullable float column, however the result ends up being a floating point
0.
I have an object created by Class::Struct that contains a field for each
row in a particular db table. If I have no value to assign to a field,
62 matches
Mail list logo
