By that do you mean DBI 1.24? That was just released a day or two ago IIRC.
Just checking,
Wes
Udlei Nattis [EMAIL PROTECTED] on 06/05/2002
03:39:00 PM
To: Stas Bekman [EMAIL PROTECTED]
cc: Perrin Harkins [EMAIL PROTECTED],
[EMAIL PROTECTED] (bcc: Wesley
Sheldahl/Lex
]
Sent: Wednesday, June 05, 2002 3:39 PM
Subject: Re: DBI Bug
hi
this problem is very very very persistent
httpd.conf
PerlModule DBI # THIS IS THE PROBLEM
PerlModule Apache::Registry
Location /perl
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
allow from all
t/REPORT don't print any problem
Udlei, please read the info at the URL I gave to you again. It says:
Whenever you send a bug report make sure to include the information
about your system by doing the following:
% cd modperl-2.0
% t/REPORT mybugreport
Also it explains how to get the
Udlei Nattis wrote:
hi, sorry my english ;)
when i add this line in httpd.conf
PerlModule DBI
or
use DBI(); in startup.conf
apache dont start, i receive this error:
/usr/local/apache-2.0/bin/apachectl: line 192: 12547 Segmentation
fault $HTTPD
/usr/local/apache-2.0/bin
Perrin Harkins wrote:
Udlei Nattis wrote:
hi, sorry my english ;)
when i add this line in httpd.conf
PerlModule DBI
or
use DBI(); in startup.conf
apache dont start, i receive this error:
/usr/local/apache-2.0/bin/apachectl: line 192: 12547 Segmentation
fault $HTTPD
/usr
hi, sorry my english ;)
when i add this line in httpd.conf
PerlModule DBI
or
use DBI(); in startup.conf
apache dont start, i receive this error:
/usr/local/apache-2.0/bin/apachectl: line 192: 12547 Segmentation
fault $HTTPD
/usr/local/apache-2.0/bin/apachectl start: httpd could
And you are sure that the CGI module is installed on the machine, right?
perl -e 'use CGI;'
from the command-line will tell you.
-Fran
Udlei Nattis wrote:
hi, sorry my english ;)
when i add this line in httpd.conf
PerlModule DBI
or
use DBI(); in startup.conf
apache dont start
Hi!
On Mon, Jun 03, 2002 at 03:40:57PM -0300, Udlei Nattis wrote:
PerlModule DBI
..
i test it in
Apache 2.0/Perl 5.8.0RC1/Modperl 1.99.02/03
Apache 2.0/Perl 5.7.3/Modperl 1.99.02/03
Apache 2.0/Perl 5.6.1/Modperl 1.99.02/03
Apache 2.0-cvs/All Perls/All Modperls
I'm not sure if Apache::DBI
Cees Hek wrote:
Quoting Jayce^ [EMAIL PROTECTED]:
I've been researching the different modules for pushing your access log to a
dbi storage vs. local file and have one question which I'm not sure any of
them are able to do yet. Perhaps somebody has already thought of this and
I'm just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
along those same lines, I forgot to mention Apache::LogSTDERR, which
is similar I suppose (though I've never used it).
Any idea where I can find this one? Searching CPAN doesn't give me anything.
Jayce^
-BEGIN PGP SIGNATURE-
Version:
Jayce^ wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
along those same lines, I forgot to mention Apache::LogSTDERR, which
is similar I suppose (though I've never used it).
Any idea where I can find this one? Searching CPAN doesn't give me anything.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've been researching the different modules for pushing your access log to a
dbi storage vs. local file and have one question which I'm not sure any of
them are able to do yet. Perhaps somebody has already thought of this and
I'm just not seeing
Jayce^ wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've been researching the different modules for pushing your access log to a
dbi storage vs. local file and have one question which I'm not sure any of
them are able to do yet. Perhaps somebody has already thought
Quoting Jayce^ [EMAIL PROTECTED]:
I've been researching the different modules for pushing your access log to a
dbi storage vs. local file and have one question which I'm not sure any of
them are able to do yet. Perhaps somebody has already thought of this and
I'm just not seeing
On Fri, 24 May 2002, Udlei Nattis wrote:
hi
i updating modperl-2.0-cvs and problem persist
now i change DynaLoader in DBI.pm to XSLoader but problem persist :(
you shouldn't need to change DBI.pm
the output of perl build/config.pl (normally should use t/REPORT) might
help. and your DBI
hi
i updating modperl-2.0-cvs and problem persist
now i change DynaLoader in DBI.pm to XSLoader but problem persist :(
can you give me one idea?
thanks
nattis
Doug MacEachern wrote:
sounds like the XSLoader vs. DynaLoader issue which only exists in 5.6.x.
try updating modperl-2.0-cvs, there
hi
sorry, my english dont is good ;)
i have one big problem,
i using apache2, modperl2 and perl 5.6.1
Apache/2.0.37-dev (Unix) mod_perl/1.99_02-dev Perl/v5.6.1
when i add this line in httpd.conf
PerlModule DBI
or
Perlrequire startup.conf
startup.conf:
use DBI;
1;
if i use it, httpd don't
sounds like the XSLoader vs. DynaLoader issue which only exists in 5.6.x.
try updating modperl-2.0-cvs, there is a better workaround in there for
the issue now.
Apache::DBI is turning the argument hashref into the cache key
with the following code,
my ($key, $val);
while (($key,$val) = each %{$args[3]}) {
$Idx .= $;$key=$val;
}
can anyone think of a good reason not to change that to something
like
map { $Idx
Ask Bjoern Hansen wrote:
Apache::DBI is turning the argument hashref into the cache key
with the following code,
my ($key, $val);
while (($key,$val) = each %{$args[3]}) {
$Idx .= $;$key=$val;
}
can anyone think of a good reason not to change
On Wed, 22 May 2002, Perrin Harkins wrote:
Apache::DBI is turning the argument hashref into the cache key
with the following code,
[...]
can anyone think of a good reason not to change that to something
like
map { $Idx .= $;$_=$args[3]-{$_} } sort keys %{$args[3]};
Good find
Ask Bjoern Hansen wrote:
Apache::DBI is turning the argument hashref into the cache key
with the following code,
my ($key, $val);
while (($key,$val) = each %{$args[3]}) {
$Idx .= $;$key=$val;
}
can anyone think of a good reason not to change
At 23:36 19.05.2002, Gregory Matthews wrote:
# Initialize the database connections for each child
Apache::DBI-connect_on_init
(DBI:mysql:database=test;host=localhost, user,password,
{ PrintError = 1, # warn() on errors
RaiseError = 0, # don't die on error
AutoCommit = 1, # commit executes
Hello again:
I figured out my Apache::DB problem with the help from Stas Bekman. Thanks!
Now on to Apache::DBI.
The documentation says NOT to use this module IF you are opening a special
connection for each of your users.
Does this mean if each user has to use a unique username/password
will
have his/her own unique file/table within this database which requires a
unique username/password to access.
So that security is handled by your program, not by the database? No
problem for Apache::DBI logins then.
- Perrin
Perrin:
Yes, my prog checks for valid username/password requests and issues the
proper response. So it sounds like Apache::DBI is a good solution then
since all users will be working under the same handle?
Gregory
At 02:03 PM 5/18/2002 -0400, you wrote:
Gregory Matthews wrote:
Does this mean
Gregory Matthews wrote:
Yes, my prog checks for valid username/password requests and issues the
proper response. So it sounds like Apache::DBI is a good solution then
since all users will be working under the same handle?
Yes, that's correct.
At 19:59 18.05.2002, Gregory Matthews wrote:
Hello again:
I figured out my Apache::DB problem with the help from Stas Bekman. Thanks!
Now on to Apache::DBI.
The documentation says NOT to use this module IF you are opening a special
connection for each of your users.
Does this mean if each
On Mon, 06 May 2002 13:30:07 +0800, Stas Bekman wrote:
[snip]
my $dbh = DBI-connect
(DBI:mysql:test:localhost, '', '',
{
PrintError = 1, # warn() on errors
RaiseError = 0, # don't die on error
AutoCommit = 1, # don't commit executes immediately
Surely the don't here is wrong?
}
) or die Cannot
that
everything is correct and I'll replace the old section with this one.
=head3 Opening Connections with Different Parameters
When CApache::DBI receives a connection request, before it decides
to use an existing cached connection it insists that the new
connection be opened in exactly the same way
F.Xavier Noria wrote:
I installed Apache::DBI and make test run no test, but the make test
of Apache::AuthCookieDBI tries to use Apache::DBI and fails because
Apache/DBI.pm in line 202 invokes Apache-module(), which it seems it is
not in the interface of the Apache class I have installed
I implemented Apache::AuthCookieDBI for the logins to my web site.
AuthCookieDBI requires Apache::DBI. This all works great.
I have also started using embperl. This seems to work fairly good as well
except it inherited the Apache::DBI from my AuthCookieDBI implementation.
Now I get 6
, Linux, DBI.
Additional Desired Skills:
Oracle, Solaris, Mysql, SMTP protocol familiarity, socket
programming, process management (fork), juggling.
If interested, please contact:
Bob Hansan
[EMAIL PROTECTED]
2731-A Prosperity Ave
Fairfax VA 22031
P: 703-289-4670
F: 703-289-4678
Got a slight problem here..
Does anyone know why there was at some point a major change in the return
value for DBI::selectall_hashref? And is there a depricated method which
still uses the original prototype?
My problem:
---
Using DBI V1.19 on my box, the reported prototype
Fixed it with common sense - using values %$result to get back my
original struct. Time to upgrade DBI.
Cheers anyway. And a great big nasty insult to the wonderful guy who went
and made the selectall_hashref method do what it logically sounds like it
should do. ;)
fiq
On Tue, 2 Apr 2002
Frazier [EMAIL PROTECTED] wrote:
If you have any idea where to find this code I would be thankful. I can
only find this..
[snip]
At 04:47 PM 3/26/02 -0500, John D Groenveld wrote:
Jeff Horn posted this a couple years ago either here or @ dbi-users
# Purpose: This version of Apache::DBI
it will probably not
work with MySQL.
Of course MySQL connects really quickly, so you can probably get
perfectly good performance without using Apache::DBI at all.
- Perrin
On 2002-03-27, Eric Frazier [EMAIL PROTECTED] wrote:
If you have any idea where to find this code I would be thankful. I can
only find this..
[snip]
At 04:47 PM 3/26/02 -0500, John D Groenveld wrote:
Jeff Horn posted this a couple years ago either here or @ dbi-users
# Purpose
I use Class::DBI + DBD::mysql in mod_perl Apache::DBI enabled
environment. I've found
SELECT LAST_INSERT_ID
would *sometimes* cause vizarre result in persistent connection. It
happens very rarely, but the phenomenon is gone away we stop-start the
httpd.
Here's a patch for Class::DBI that fix
There are databases that allow you to change the current user without
reconnecting. In fact someone posted a module to do this a while back,
but I can't remember which database it was for. Seems like it was
Sybase or Informix.
Jeff Horn posted this a couple years ago either here or @ dbi
Hi,
If you have any idea where to find this code I would be thankful. I can only
find this..
http://aspn.activestate.com/ASPN/Mail/Message/perl-DBI/298774
Thanks,
Eric
At 04:47 PM 3/26/02 -0500, John D Groenveld wrote:
There are databases that allow you to change the current user without
On Sun, 24 Mar 2002, Andrew Ho wrote:
What would be ideal is if the database would allow you to change the
user on the current connection. I know PostgreSQL will allow this
using the command line interface psql tool (just do \connect
database user), but I'm not sure if you can do this using DBI
Hi,
It might well be that in my particular case, I don't have anything to worry
about the connection time per each user most likely won't kill me or even
cause problems at first. But I am trying to build a system, and I don't want
to skip any reasonable efficences I can build in from the start.
Ed Grimm wrote:
First, I'll suggest that there are hopefully other areas you can look at
optimizing that will get you a bigger bang for your time - in my test
environment (old hardware), it takes 7.4 ms per
disconnect/reconnect/rebind and 4.8 ms per rebind. Admittedly, I'm
dealing with LDAP
be ideal is if the database would allow you to change the
user on the current connection. I know PostgreSQL will allow this using
the command line interface psql tool (just do \connect database
user), but I'm not sure if you can do this using DBI.
If this was possible, then you could always connect
Hello,
CHWhat would be ideal is if the database would allow you to change the
CHuser on the current connection. I know PostgreSQL will allow this using
CHthe command line interface psql tool (just do \connect database
CHuser), but I'm not sure if you can do this using DBI.
CH
CHDoes anyone know
of the
other pages use Apache::DBI with a web-user DB login. This allows us
take advantage of the persistent connections for most of the requests.
One trick here, if you're using the DB to enforce business rules based
on the login, then you'll have to encorporate those rules into your
mod_perl programs
Hi,
I was all happy and rolling along when I read this in the docs.
With this limitation in mind, there are scenarios, where
the usage of Apache::DBI is depreciated. Think about a
heavy loaded Web-site where every user connects to the
database with a unique userid. Every
Hello,
EFI will have many different users, users as in database users. So am I
EFjust screwed and won't be able to keep connections open?
Do you mean users as in actual RDBMS level users? In other words, when you
say database users you mean different username/passwords used from, say,
a
On Wed, 20 Mar 2002, Stas Bekman wrote:
Doug Silver wrote:
I don't know if this is a PostgreSQL oddity, but in the startup.pl file, I
can have the entry like so and it seems to start fine:
Apache::DBI-connect_on_init
(dbi:pg(PrintError=1,AutoCommit=0):, , )
or die Cannot
I don't know if this is a PostgreSQL oddity, but in the startup.pl file, I
can have the entry like so and it seems to start fine:
Apache::DBI-connect_on_init
(dbi:pg(PrintError=1,AutoCommit=0):, , )
or die Cannot connect to database: $DBI::errstr;
The error log shows a couple of
Apache
Doug Silver wrote:
I don't know if this is a PostgreSQL oddity, but in the startup.pl file, I
can have the entry like so and it seems to start fine:
Apache::DBI-connect_on_init
(dbi:pg(PrintError=1,AutoCommit=0):, , )
or die Cannot connect to database: $DBI::errstr;
The error log
I can't seem to get Apache::DBI to start up properly.
Here's my startup.pl:
#!/usr/bin/perl -w
use strict;
use Apache ();
use Apache::Status ();
use Apache::DBI (); # This *must* come before all other DBI modules!
use Apache::Registry;
use CGI ();
CGI-compile(':all');
use CGI
at 18:09, Doug Silver wrote:
I can't seem to get Apache::DBI to start up properly.
Here's my startup.pl:
#!/usr/bin/perl -w
use strict;
use Apache ();
use Apache::Status ();
use Apache::DBI (); # This *must* come before all other DBI modules!
use Apache::Registry;
use CGI
Ok, I found it, but this has got to be some kind of bug.
This works:
Apache::DBI-connect_on_init(dbi:pg:demo,demo);
This doesn't:
Apache::DBI-connect_on_init(dbi:Pg:demo,demo);
That's right, putting 'dbi:pg' in lowercase made it work. I looked through
some old newsgroup stuff and saw someone
Weird, although I bet if you had straced the apache processes you would
have seen the File not found.
For some reason I recall DBD Drivers being case sensitive.
On Thu, 2002-03-14 at 20:06, Doug Silver wrote:
Ok, I found it, but this has got to be some kind of bug.
This works:
Apache::DBI
On Sat, 9 Mar 2002, Axel Andersson wrote:
Okay, so I read up on Apache::DBI, but I still have a question or two.
Specifically, am I supposed to keep my use DBI, DBI-connect(), and
everything DBI related and not change a single thing in my source
What did you read? Here are the first six
Hi
Okay, so I read up on Apache::DBI, but I still have a question or two.
Specifically, am I supposed to keep my use DBI, DBI-connect(), and
everything DBI related and not change a single thing in my source after
I've added Apache::DBI-connect_on_init() in startup.pl?
Right, I guess that's all
Once you use Apache::DBI; all calls to DBI should transparently use it.
You should not have to change any of your other code (connect
statements, etc)
-Original Message-
From: Axel Andersson [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 08, 2002 8:51 PM
To: modperl
Subject: About
Marty == Marty J Rogers [EMAIL PROTECTED] writes:
Marty I had tried that, with the same result. (does Apache::DBI
Marty overload the DBI methods?) Full error is as follows. Again,
Marty any help is _highly_ appreciated.
You must specify the full package name to the connect_on_it
I had tried that, with the same result. (does
Apache::DBI overload the DBI methods?) Full
error is as follows. Again, any help is _highly_
appreciated.
Marty
[error] Can't locate object method connect_on_init via package Apache::DBI at
/etc/httpd/conf/startup.pl line 28.
Compilation failed
(doesApache::DBI overload the DBI methods?)
No, it doesn't. It uses Apache and DBI. Did you install the package via the
"Makefile.PL" stanza? Maybe you should just install it another time. On the
other hand, Apache::DBI doesn't export anything. Try calling it with the
package name
Marty J. Rogers wrote:
[snip]
From httpd.conf:
PerlModule Apache::DBI CGI DBD::mysql \
Apache::AuthenDBI
PerlRequire /path/to/startup.pl
Alias /perl/ /path/to/perl
PerlModule Apache::Registry
Location /perl
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
allow from all
Hi all,
i have just installed DBI-1.20, ApacheDBI-0.88 and DBD-Oracle-1.12 on a
tru64 Unix 5.1a. Also installed is Oracle 8.1.7 with Oracle supplied Apache
1.3.12 and Oracle supplied perl 5.005_03.
After some problems i got it work together with DBD::Oracle. The problem now
is as follows:
I run
Hi there,
On Fri, 8 Feb 2002 [EMAIL PROTECTED] wrote:
I run the following script (just select the dbname and hostname from a
function, commented out host user and password)
[snip]
abba02.orgdv perl test4.pl
Content-type: text/plain
DB: ENTWICKL auf Maschine: abbaentwickel.orgdv
DBI
At 4:09 PM +0100 2/8/02, [EMAIL PROTECTED] wrote:
Hi all,
i have just installed DBI-1.20, ApacheDBI-0.88 and DBD-Oracle-1.12 on a
tru64 Unix 5.1a. Also installed is Oracle 8.1.7 with Oracle supplied Apache
1.3.12 and Oracle supplied perl 5.005_03.
After some problems i got it work together
I just experienced an issue where I upgraded MySQL, and had to reinstall the
DBD::Mysql module to match the new client libraries (libmysqlclient.so.10 -
I was getting messages about an ISA directive not found). After reinstalling
the MySQL module, DBI began to spew errors at me when I tried
I thought I saw a posting on how to retrieve an independent database handle
from Apache::DBI using a certain method call (instead of from the shared
$dbh for the child). Does anyone know where this documentation may reside
(If it is possible).
Thanks,
Stathy G. Touloumis wrote:
I thought I saw a posting on how to retrieve an independent database handle
from Apache::DBI using a certain method call (instead of from the shared
$dbh for the child). Does anyone know where this documentation may reside
(If it is possible).
I'm not sure what
I'm not sure what you mean, really, but perhaps you mean
dbi_connect_method?
Did you mean specifying this argument like so ?
DBI-connect( $driver, $u, $p, { dbi_connect_method= 'connect' } );
I will see if this is what I am looking for. Thanks for the reference : )
Stathy G. Touloumis wrote:
I'm not sure what you mean, really, but perhaps you mean
dbi_connect_method?
Did you mean specifying this argument like so ?
DBI-connect( $driver, $u, $p, { dbi_connect_method= 'connect' } );
yes, you never call Apache::DBI-connect() directly.
I
Stathy G. Touloumis wrote:
I'm not sure what you mean, really, but perhaps you mean
dbi_connect_method?
Did you mean specifying this argument like so ?
DBI-connect( $driver, $u, $p, { dbi_connect_method= 'connect' } );
I will see if this is what I am looking for. Thanks
, 2002 1:11 AM
To: [EMAIL PROTECTED]
Subject: DBI/MySQL causing SIGPIPE
My setup is apache/modperl+Apache::DBI with MySQL driver. On server startup
in every httpd child a few queries that are executed very often are
prepared. When the Apache::Registry scripts run values are bound to the
cursors
I'm working on a web application which obtains data via a legacy system
rather than DBI. Using DBI is (unfortunately) not an option. The machine
where the web application runs cannot run the legacy system. Thus, the
setup looks somewhat like this:
DB = DB Query (Legacy) = Apache/mod_perl
Has anyone done such a thing before?
No doubt.
Can someone point me to docs or
modules which could help doing this?
Perhaps raw sockets might be a consideration. However, Apache is
great middleware, so I tend to use it in cases like this. You might
want to use a session-based approach
Hi there,
On Sat, 17 Nov 2001, Dau Hee wrote:
[snip,snip]
I also use up2date to upgraded my glibc to 2.2.4 from 2.2.2.
Why? If it ain't broke, don't mend it.
After the glibc upgrade, I cannot get Apache to run.
Not too surprising after upgrading glibc. Have you recompiled Perl
itself?
Ged Haywood [EMAIL PROTECTED] writes:
Hi there,
On Sat, 17 Nov 2001, Dau Hee wrote:
[snip,snip]
I also use up2date to upgraded my glibc to 2.2.4 from 2.2.2.
Why? If it ain't broke, don't mend it.
Because RedHat will have fixed stuff. For some values of fixed.
I normally roll my
Hi
I am running on Redhat 7.1 with Apache/1.3.22 and
mod_perl/1.26. My perl version is 5.6.1, my DBI is at
1.20, DBD-Oracle is at 1.12, ApacheDBI at 0.88 and
Oracle is at 8.1.7.0.1. I also use up2date to upgraded
my glibc to 2.2.4 from 2.2.2.
After the glibc upgrade, I cannot get Apache to run
Hi!
Apache::DBI is great module of course because it makes things transparent. But
it also makes things confusing. In few cases we have to open and close
connection to database on each request (in particular Oracle on NT gives a lot
of trouble with cached connections).
Currently in such cases
-Original Message-
From: Andrei A. Voropaev [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 15, 2001 6:44 AM
To: [EMAIL PROTECTED]
Subject: Apache::DBI usage
Hi!
Apache::DBI is great module of course because it makes things
transparent. But
it also makes things
I think I have found a curious bug in DBI. It seems that since DBI 1.15
- 1.20, when you bring up apache/mod_perl and execute queries against
the database handle in the parent process (startup.pl), multiple
connections result against the database. If I switch to DBI 1.14, no
such problem occurs
Perrin Harkins wrote:
Are there any benchmark comparisons between apache::dbi and mysql
relay?
I've never heard of this mysql relay before. A Google search found
this:
http://www.firstworks.com/sqlrelay.html
Is that it? Looks interesting!
On http://www.firstworks.com/sqlrelay
On http://www.firstworks.com/sqlrelay/programming/perldbd.html it says:
For the duration of the session, the client stays connected to a
database connection daemon. While one client is connected, no other
client can connect. Care should be taken to minimize the length of a
session.
What I don't understand is why they separate the listener and database
connection daemons if you always need one of each to do anything.
Probably for scalability. The database engines are doing the work and
the sooner they can free themselves up (due to a slow client, for example),
the
Matt J. Avitable wrote:
Hi,
I've written a search engine that searches for jobs in a database based
on keywords. I'm assembling a string of sql and then submitting it to
the database based on the user's search criteria. It's working but is
It sounds like you are writing a web front end
Mark Maunder wrote:
I've started using
MySQL's MATCH/AGAINST with fulltext indexes instead, and it is extremelly
fast (!!), but am waiting for a feature that's available in mysql 4.0 (due
end of this month) that allows you to use +word and -word syntax to specify
required or unwanted
in the DESTROY stack
was blocking, and holding the child up for 12m. I'm guesing the
underlying DBD::Oracle code was trying to do a nice shutdown on the
dbh, but obviously couldn't.
Quick hack:
Tweak Apache::DBI to keep the ejected dbh in scope, in a global @array
or something, and perform
, but obviously couldn't.
Quick hack:
Tweak Apache::DBI to keep the ejected dbh in scope, in a global @array
or something, and perform a daily/weekly restart on apache.
Are you loading the Oracle driver in the parent process (with startup.pl)?
I think I remember this sometimes causing problems with re
. We had a good reason for that, too (to do with the Oracle
driver overloading alarm(), so that the second alarm in
alarm(20);
$dbh = DBI-connect(dbi:Oracle:..., ...);
alarm(0);
cleared a different type of alarm that the first call set ...)
PH Another solution is to have the child
PH Another solution is to have the child process exit if the ping
PH fails. You get one failed request, but you clear out the messed
PH up processes quickly and replace them with new ones that can
PH connect safely.
Yeah, good point. Although our poor little WAP service (for
Hello,
Are there any benchmark comparisons between apache::dbi and mysql relay?
We're planning on having four sql servers, one of them will do all of the
writes to the db and the other three will only be used for reads from the db.
The data in the db that is doing the writing
Are there any benchmark comparisons between apache::dbi and mysql
relay?
I've never heard of this mysql relay before. A Google search found
this:
http://www.firstworks.com/sqlrelay.html
Is that it? Looks interesting!
We're planning on having four sql servers, one of them will do all
Hi,
No, we use Solaris 8.
Cheers,
Markus
-- Original Nachricht --
Are you using redhat 7.1?
Tor.
Markus Linke wrote:
Hi,
we have a problem with Apache::DBI ... after activating it in httpd.conf
the server-start fails when using Apache::DBI.
The installation of mod_perl and mod_ssl
Hi,
we have a problem with Apache::DBI ... after activating it in httpd.conf
the server-start fails when using Apache::DBI.
The installation of mod_perl and mod_ssl brought up no error messages.
Perl itself works fine
Perl DBI works fine
Appache works fine
Apache Mod_SSL works fine
Apache
Are you using redhat 7.1?
Tor.
Markus Linke wrote:
Hi,
we have a problem with Apache::DBI ... after activating it in httpd.conf
the server-start fails when using Apache::DBI.
The installation of mod_perl and mod_ssl brought up no error messages.
Perl itself works fine
Perl DBI works
Markus Linke wrote:
/usr/local/apache/bin: apachectl configtest
Syntax error on line 1235 of /usr/local/apache/conf/httpd.conf:
Can't load
'/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/auto/DBI/DBI.so' for
module DBI: ld.so.1: /usr/local/apache/bin/httpd: fatal: relocation
error
it
PerlModule Apache::Status
PerlModule Apache::Registry
PerlModule Apache::ASP
PerlModule Apache::DBI
/IfModule
/snip
and line 202 in DBI.pm is:
snip
Apache::Status-menu_item(
'DBI' = 'DBI connections
Your script uses an END block to disconnect. If you use
Apache::Registry, that will not be run until the server is shut down.
With Apache::DBI, you should get one connection per Apache process, and
they'll stay open. If you are changing the login parameters (i.e.
different user each
Your script uses an END block to disconnect. If you use
Apache::Registry, that will not be run until the server is shut down.
With Apache::DBI, you should get one connection per Apache process, and
they'll stay open. If you are changing the login parameters (i.e.
different user each
On Thu, 13 Sep 2001, DJ (David J Radunz) wrote:
use strict;
use vars ($dbh);
You don't need this with Apache::DBI. Globals in general should be
avoided/used with extreme caution.
use mod_perl;
Don't need this either.
1;
END {
$dbh-disconnect;
}
Put this before the '1;' or just
201 - 300 of 856 matches
Mail list logo
