Yan Zhu wrote:
> Ok, here we go.
>
> I rebooted the machine and reclaimed all my memory.
> And I ran test.pl on a db that has buffered logging.
>
> I let 50K records passed before I stopped the program.
>
> according to test.pl, the size stablized to 827 very quickly and stayed there
> till the e
True :-)
> -Original Message-
> From: Tim Bunce [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 02, 2002 5:25 PM
> To: Sterin, Ilya
> Cc: 'Ian Harisay'; [EMAIL PROTECTED]
> Subject: Re: UTF8 characters
>
>
> Unless, of course, you can show that the DBI or a driver
> doesn't do-the-r
Ok, here we go.
I rebooted the machine and reclaimed all my memory.
And I ran test.pl on a db that has buffered logging.
I let 50K records passed before I stopped the program.
according to test.pl, the size stablized to 827 very quickly and stayed there
till the end.
# 8 R 0 2433 1645
I should also have added "or maybe the test is not tickling the bug".
Can you update the test code I sent so that the types of the column match
the types in your tables? Does it leak then?
Have you allocated enough swap space? You say that you are running out of
memory, but how do you know th
Yan Zhu,
If your Perl process is not growing (and the SZ column *is* the one to
monitor; it looks good but you need more data points than you show), then
there isn't a leak in Perl + DBI + DBD::Informix. You may have to track
down what the database server is doing. How much memory is in your
Unless, of course, you can show that the DBI or a driver doesn't
do-the-right-thing. Which is quite possible :)
Tim.
On Tue, Apr 02, 2002 at 05:11:30PM -0500, Sterin, Ilya wrote:
> This also has really nothing to do with DBI, so any further questions
> should be directed to appropriate groups.
>
This also has really nothing to do with DBI, so any further questions
should be directed to appropriate groups.
Ilya
> -Original Message-
> From: ianh@[170.89.51.94] [mailto:ianh@[170.89.51.94]] On
> Behalf Of Ian Harisay
> Sent: Tuesday, April 02, 2002 5:01 PM
> To: [EMAIL PROTECTED]
>
As far as storing them in Oracle, I'd use just a long raw or something,
where it will just store raw binary chars. Which will make it
application specific to convert, etc...
Ilya
> -Original Message-
> From: ianh@[170.89.51.94] [mailto:ianh@[170.89.51.94]] On
> Behalf Of Ian Harisay
>
Well, depends on how you'll be pulling them. Are they going to be
actual encoding values, or characters. Also depends on whether the
browser supports it or not.
You should use the utf8 pragma.
use utf8;
Which will utf8 all your string automatically.
Ilya
> -Original Message-
> From:
Hello, everybody.
I use DBD::ADO to connect to the DB using OLE DB Provider.
To generate result form I need some information about columns
(likes in DBD::ODBC ColAttributes).
Is there is a way to get same information from DBD::ADO?
Thanks in advance,
Vassiliy
Does anyone have any experience with handling UTF8 characters?
I need to be able to pull the UTF8 chars from a web form and store them in
Oracle.
Thanks,
-Ian
On Tue, Apr 02, 2002 at 02:58:03PM -0600, Koie Smith wrote:
>
> i'm wanting to create a cgi file that verify's customer number/password..
>
> i think i have it partially correct..
>
> SELECT custnum FROM support WHERE custnum=$enteredcustnum;
> SELECT password FROM support WHERE password=$enter
The query looks correct, just need to make $enteredcustnum, etc... equals
the actual entered values. You have to look at the CGI documentation for
that.
Ilya
-Original Message-
From: Koie Smith
To: [EMAIL PROTECTED]
Sent: 4/2/02 1:58 PM
Subject: another dbi question
ok,
i'm wanting t
ok,
i'm wanting to create a cgi file that verify's customer number/password..
i think i have it partially correct..
SELECT custnum FROM support WHERE custnum=$enteredcustnum;
SELECT password FROM support WHERE password=$enteredpw;
I think i have that part, but i dont know how to make them com
Michael Peppler <[EMAIL PROTECTED]> wrote:
> See the new 'exec proc" syntax (with placeholders) that is supported
> in 0.94. This does away with the need to declare OUTPUT parameters as
> T-SQL variables.
Is this also in 0.93 as the manpage suggests? We have installed 0.93 and
upgrading i
here is my result, the SZ ( I assume that is the size we should be looking at)
did stablize at 827. However, I have no more memory left on my box at this point,
they all leaked out. So I am going to wait till tonight and reboot the machine and try
again.
yan
# DBI->connect('dbi:Informix:pdqtest'
perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
Platform:
osname=solaris, osvers=2.8, archname=sun4-solaris
uname='sunos solaris 5.8 generic sun4u sparc sunw,ultra-5_10 '
config_args='-Dcc=gcc -de'
hint=recommended, useposix=true, d_sigaction=defi
Before the database stuff, put the following:
print "Content-type: text/html\n\n";
There is quite a bit more to CGI programming, but the above
statement prints the minimum CGI header.
glen
-Original Message-
From: Koie Smith [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 02, 2002 12
Koie
I put some code in your original email... This is an example
connecting to oracle, but should be pretty close. You will just need to
dress up the select statement.
Aaron.
At 12:08 PM 4/2/2002, you wrote:
>In my mysql database i have a field called custnum and password. How
>w
just a general suggestion, since you seem to be starting with the DBI:
_do_ use placeholders (check the fine manual about those). they make
everybody's life easier and safer, and are really not complicated at
all.
if you would've been using placeholders, you'd be tackling more
interesting problem
On Tue, Apr 02, 2002 at 12:51:49PM -0500, [EMAIL PROTECTED] wrote:
>
> I have a proof-of-concept module that does this, tentatively called
> DBIx::Sybase::StoredProc,
I'd suggest just Sybase::StoredProc
Tim.
ok here is what i got so far..
~~~
use DBI;
my $dbh = DBI->connect( "dbi:mysql:nextek", "root", "" )
or die "Can't connect to MySQL Database: $DBI:errstr\n";
my $sth = $dbh->prepare( "SELECT * FROM support" );
$sth->execute;
while ( my @row = $sth->fetchrow_array() ) {
print "
You would call a select query and fetch the results. Then display them.
All of this is in the perldoc DBI and perldoc DBD::mysql
Ilya
-Original Message-
From: Koie Smith
To: [EMAIL PROTECTED]
Sent: 4/2/02 11:08 AM
Subject: dbi with mysql help
In my mysql database i have a field called
In my mysql database i have a field called custnum and password. How would diplay
this information to screen from the following test.cgi file...
~~
use DBI;
my $dbh = DBI->connect( "dbi:mysql:nextek", "root", "" )
or die "Can't connect to MySQL Database: $DBI:
"Pepin, Joseph D (Joe), SOLCM" wrote:
>
> >From: Jeff Zucker [mailto:[EMAIL PROTECTED]]
> >Sent: Tuesday, April 02, 2002 4:36 AM
> >Tim Bunce wrote:
> >>
> >> On Mon, Apr 01, 2002 at 09:53:20AM -0800, Jeff Zucker wrote:
> >> > "Pepin, Joseph D (Joe), SOLCM" wrote:
> >>
> >> > > However, DBD::CSV
IT'S ALIVE
I would swear that I had tried this before, but it now works. Below
is the UPDATE line that works. I may, no must, be an idiot. I would
honestly swear that I did this at least twice before, but here it is
working.
$dbh->do(qq{UPDATE systems SET $set WH
[EMAIL PROTECTED] writes:
> Where I work, we use a lot (thousands) of Sybase stored procedures and have only
> recently adopted DBI and DBD::Sybase. Is there any DBIx-type module out there
> that handles fetching the return status and output params in an intuitive way?
> A quick search of CPA
Hi all,
Where I work, we use a lot (thousands) of Sybase stored procedures and have only
recently adopted DBI and DBD::Sybase. Is there any DBIx-type module out there
that handles fetching the return status and output params in an intuitive way?
A quick search of CPAN has revealed nothing.
I
OK. Sorry for my being stupid. Everyone keeps telling me the same
thing, and I must be doing something wrong here. Let me try to make clear
how I am handling the SET parameter.
The SET parameter ($set) is actually built earlier in the Perl
script. I scavenged this portion of t
>From: Jeff Zucker [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, April 02, 2002 4:36 AM
>Tim Bunce wrote:
>>
>> On Mon, Apr 01, 2002 at 09:53:20AM -0800, Jeff Zucker wrote:
>> > "Pepin, Joseph D (Joe), SOLCM" wrote:
>>
>> > > However, DBD::CSV complains that TEXT is a reserved word
>>
>> Putting dou
That looks a bit off to me.
Try something like this:
$dbh->do(qq{UPDATE systems SET column_name = $value WHERE Name =
$name});
On Tue, 2002-04-02 at 12:01, NIPP, SCOTT V (SBCSI) wrote:
> New problem now. I appear have resolved my earlier problems. The
> final issue appears to have been t
On Tue, Apr 02, 2002 at 11:01:41AM -0600, NIPP, SCOTT V (SBCSI) wrote:
> New problem now. I appear have resolved my earlier problems. The
> final issue appears to have been that the SQL statement was interpreting the
> WHERE clause as having multiple arguments. Quoting the where clause se
Hello All!
my name is Koie and i'm working on a support database for a very small company i work
for. We are wanting to create an email support system and i'm going to be using mySQL
as the database part. I have activestate perl installed and the DBI module installed
on my windows 2000 sbs. an
At 12:01 PM 4/2/2002, NIPP, SCOTT V (SBCSI) wrote:
> New problem now. I appear have resolved my earlier problems. The
>final issue appears to have been that the SQL statement was interpreting the
>WHERE clause as having multiple arguments. Quoting the where clause seems
>to have resolve
New problem now. I appear have resolved my earlier problems. The
final issue appears to have been that the SQL statement was interpreting the
WHERE clause as having multiple arguments. Quoting the where clause seems
to have resolved the error, but the data still is not making it into th
I actually have that covered, I think. The variable $set actually
expands to something like ip='192.168.0.1' , speed='450' , etc. This
portion is working OK, I think. I can print the SQL statement and then
paste it into the MySQL Console and it UPDATEs OK. Below is the portion of
code
Following another suggestion, I tried using the 'qq' quoting method
and received the following error.
DBD::mysql::db do failed: Unknown column 'harry' in 'where clause' at
sys_db_update1.pl line 41, line 81.
-Original Message-
From: NIPP, SCOTT V (SBCSI)
[mailto:[EMAIL PROTECTED
A bit more information... Here is the error message from the Perl
script on the UPDATE failure.
DBD::mysql::db do failed: You have an error in your SQL syntax near 'WHERE
Name ='$name' LIMIT 1' at line 1 at sys_db_update1.pl line 41, line
81.
-Original Message-
From: NIPP, SCOT
Wow!!! This is one awesome mailing list. I really appreciate all
of the responses. Several of your suggestions have helped me to narrow in
on the problem. Here is what I have come up with so far, but still not
quite there.
my $test = $dbh->prepare("SELECT * FROM systems WHERE Name
Now that I read this more carefully I have some more thoughts on this.
You need to do some error checking when you call execute. Simply
checking the value of $test won't do it as $test is set to a statement
handle by prepare. The line "if($test)" should always be true as $test
will always be non
At 10:50 AM 4/2/2002, NIPP, SCOTT V (SBCSI) wrote:
> I added a COMMIT immediately after the UPDATE, and still have the
>same problem. Below is exactly what I added, with the lines immediately
>before and after.
>
> $dbh->do(q{UPDATE systems SET = $set WHERE Name = $name LIMIT 1}
Instead of using $dbh->do("COMMIT");
try doing:
$dbh->do(q{UPDATE systems SET = $set WHERE Name = $name LIMIT 1});
$dbh->commit;
Gordon
-Original Message-
From: NIPP, SCOTT V (SBCSI) [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 02, 2002 9:51 AM
To: 'Tielman J de Villiers'
Cc: '[EMAIL
Scott,
The first step in debugging a problem like this is to have your perl script
print out the Update statement and then cut and paste that statement into
your usual database frontend and run it. (In oracle it sould be sql*plus, I
don't know what it is in MySQL). This will tell you if there's a
I added a COMMIT immediately after the UPDATE, and still have the
same problem. Below is exactly what I added, with the lines immediately
before and after.
$dbh->do(q{UPDATE systems SET = $set WHERE Name = $name LIMIT 1});
$dbh->do("COMMIT"); #Just added!!!
}
Thanks, for the response Jeff, its very much appreciated. I posted it on the
wrong list. Thanks, again.
This is a solaris 8 server attempting to connect to a Solaris 8 progress
server.
here's my main env settings:
UDBCINI=/usr/openlink/bin/udbc.ini
ODBCHOME=/usr/openlink/odbcsdk
$ODBCHOME=/usr/
Check how you connect -- if Autocommit is not on, then you need to commit
after you update
Tielman J de Villiers
BondNet Pty Ltd
-Original Message-
From: NIPP, SCOTT V (SBCSI) [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 02, 2002 5:40 PM
To: '[EMAIL PROTECTED]'
Subject: UPDATE Statem
Hey guys. I am still quite new to the database world and obviously
in need of help. Not sure if I am just stupid, or if there is really very
little information to be found concerning UPDATE statements. I am working
on a MySQL database with Perl 5.6.0 and the latest DBI version. I am do
Michael,
Thanks for you response. I have forwarded it on to the system admins here
who will hopefully agree to install the newest versions of DBI and
DBD::Sybase. :) I really appreciate your help.
- Patty
In a message dated 4/2/2002 10:03:22 AM Eastern Standard Time,
[EMAIL PROTECTED] writ
Ah.
Well then I suggest you upgrade DBD::Sybase (and while you are at it,
also upgrade DBI). Current DBD::Sybase is 0.94 - a *lot* of bugs have
been fixed.
Michael
[EMAIL PROTECTED] writes:
> I'm using a Sybase database, so DBD::Sybase.The DBI.pm is version 1.13
> Revision 10.25 and Syb
Thanks to everyone that offered input (too many to mention), the issue has
been fixed. Even though I tried copying all of the oracle owner's
environment to root, and the root account could log in to oracle, the make
test didn't work. However, running the "perl Makefile.PL -p" and "make" as
root,
I'm using a Sybase database, so DBD::Sybase.The DBI.pm is version 1.13
Revision 10.25 and Sybase.pm is version 0.21 Revision 1.21.
- Patty
In a message dated 4/1/2002 6:05:04 PM Eastern Standard Time,
[EMAIL PROTECTED] writes:
>
> [EMAIL PROTECTED] writes:
> > Hi -
> >
> > I have been
of course, will get right on it, thank you!
Jonathan Leffler wrote:
> Previously sent to Yan Zhu directly - bounced by onion.perl.org.
> Attempting a resend from my subscribed email address...
>
> Dear Yan Zhu,
>
> The attachment is the test case I created derived from the information
> you sen
Tim Bunce wrote:
>
> On Mon, Apr 01, 2002 at 09:53:20AM -0800, Jeff Zucker wrote:
> > "Pepin, Joseph D (Joe), SOLCM" wrote:
> > >
> > > However, DBD::CSV complains that TEXT is a reserved word
> >
> > Yep, TEXT is a data type in DBD::CSV and therefore a reserved word and
> > therefore illegal as
Previously sent to Yan Zhu directly - bounced by onion.perl.org.
Attempting a resend from my subscribed email address...
Dear Yan Zhu,
The attachment is the test case I created derived from the information
you sent. I tested it on Solaris 7 with Perl 5.7.3, DBI 1.21,
DBD::Informix 1.00.PC2, ESQ
On Mon, Apr 01, 2002 at 09:53:20AM -0800, Jeff Zucker wrote:
> "Pepin, Joseph D (Joe), SOLCM" wrote:
> >
> > However, DBD::CSV complains that TEXT is a reserved word
>
> Yep, TEXT is a data type in DBD::CSV and therefore a reserved word and
> therefore illegal as an identifier. You can get aro
55 matches
Mail list logo
