It looks like your PostgreSQL installation is trying to do IDENT
authentication, instead of MD5. So, it's checking the user your script is
running as, and trusting that since you managed to log on with your
username/password already, it'll trust you to log into the database.
While this isn't
I've set Apache::DBI::DEBUG to 2, and I'm not seeing _any_ messages
(from it) in the error log. Apache::Status lists Apache DBI, but
lists no database connections.
A long time ago, one problem used to be that if your connect to
Postgres was idle for too long ( 8 hours ) the connection would
On Mon, 18 Aug 2003, wrote:
Date: Mon, 18 Aug 2003 16:57:13 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Apache::DBI
What's the diference between DBI and Apache::DBI?
Have you bothered to read the docs at all?
http://search.cpan.org/author/TIMB/DBI-1.37/DBI.pm
On Tue, 2003-07-22 at 17:15, Michael A Nachbaur wrote:
If I do a $dbh-disconnect, I know it will be ignored by Apache::DBI, but is
it smart enough to pass something back to the database server telling it that
it can purge temporary data?
No. If you come up with a way to do that, you can add
On Tue, 22 Jul 2003 14:15:41 -0700
Michael A Nachbaur [EMAIL PROTECTED] wrote:
Hello all,
I know from a DBI perspective, when using PostgreSQL, if I create a
temporary database table it will automatically go *poof* and be
deleted when the database connection is closed (or when the
On Thu, 6 Mar 2003, Stas Bekman wrote:
re: rollback, the DBD drivers will perform the normal disconnect(), but
without doing the physical disconnect, and normal DESTROY, without destroying
the datastructures which maintain the physical connection, so there shouldn't
be much to change for this
Ask Bjoern Hansen wrote:
On Thu, 6 Mar 2003, Stas Bekman wrote:
re: rollback, the DBD drivers will perform the normal disconnect(), but
without doing the physical disconnect, and normal DESTROY, without destroying
the datastructures which maintain the physical connection, so there shouldn't
be
On Fri, 7 Mar 2003, Stas Bekman wrote:
If the physical connection is still there, would the database server
do a rollback?
If earlier the rollback worked correctly with
$dbh ||= connect();, this will work the same, since it performs the same
operation, but rips off only parts of $dbh,
Ask Bjoern Hansen wrote:
On Fri, 7 Mar 2003, Stas Bekman wrote:
If the physical connection is still there, would the database server
do a rollback?
If earlier the rollback worked correctly with
$dbh ||= connect();, this will work the same, since it performs the same
operation, but rips off only
On Wed, 5 Mar 2003, Stas Bekman wrote:
Great. I've already committed that patch.
Perhaps Ask could load 'Apache::compat' inside Apache::DBI if mp2 is used. Or
to use the mp2 API if mp2 is used.
That seems like it'll be an easy solution. I thought loading
Apache::compat would have global
Ask Bjoern Hansen wrote:
On Wed, 5 Mar 2003, Stas Bekman wrote:
Great. I've already committed that patch.
Perhaps Ask could load 'Apache::compat' inside Apache::DBI if mp2 is used. Or
to use the mp2 API if mp2 is used.
That seems like it'll be an easy solution. I thought loading
Stas Bekman wrote:
FWIW, we are discussing the internal DBI pooling mechanism at the
dbi-dev list and having already a sort-of-working prototype. So
hopefully there will be no need for Apache::DBI in the near future, as
DBI will be able to handle pooling internally. However it may take some
Perrin Harkins wrote:
Stas Bekman wrote:
FWIW, we are discussing the internal DBI pooling mechanism at the
dbi-dev list and having already a sort-of-working prototype. So
hopefully there will be no need for Apache::DBI in the near future, as
DBI will be able to handle pooling internally.
On Today at 11:16am, SB=Stas Bekman [EMAIL PROTECTED] wrote:
SB FWIW, we are discussing the internal DBI pooling mechanism at the
SB dbi-dev list and having already a sort-of-working prototype. So
SB hopefully there will be no need for Apache::DBI in the near future, as
SB DBI will be able to
Haroon Rafique wrote:
On Today at 11:16am, SB=Stas Bekman [EMAIL PROTECTED] wrote:
SB FWIW, we are discussing the internal DBI pooling mechanism at the
SB dbi-dev list and having already a sort-of-working prototype. So
SB hopefully there will be no need for Apache::DBI in the near future, as
SB
FWIW, we are discussing the internal DBI pooling mechanism at the dbi-dev list
and having already a sort-of-working prototype. So hopefully there will be no
need for Apache::DBI in the near future, as DBI will be able to handle pooling
internally. However it may take some time, as the drivers
[EMAIL PROTECTED] wrote:
Any plans to make Apache::FakeRequest work well enough to make this
possible?
[EMAIL PROTECTED] wrote:
As for mod_perl 1.0, I'm not sure, but if you can make it useful
that would be cool.
A while back Andrew Ho posted his script, apr, that is similar to
Also remember, that you can't test modules that require mod_perl
to run from
the command line. You'd have the same result with mod_perl 1.0
Thanks, I didn't know that at all as I test all my modules that way and have
never had a problem.. Of course most are not mod_perl specific.
-Chris
[EMAIL PROTECTED] wrote:
Any plans to make Apache::FakeRequest work well enough to make this
possible?
There are plans. Here is an entry from modperl-2.0/todo/api.txt:
Apache::FakeRequest:
since APR can be used outside of httpd, and we can alloc request_rec
and similar structures, it should be
Chris Faust wrote:
Hey Helmut,
Yes, I'm sure its Apache::DBI - when I try to check for it directly via
perl -MModule::Name, I get the error..
Where is a copy paste from the command line.
[chrisf@web1 chrisf]$ perl -MApache::DBI -e 0
Can't locate Apache/Constants.pm in @INC (@INC contains:
Hi Chris,
are you shure that is is the Apache::DBI, that needs the Apache::Constants
or is it another module?
For me Apache::DBI loads without problems (2.044/1.9908/5.8) even without
the
use compat(); compatibility layer.
Helmut
--On Friday, February 14, 2003 09:00:31 -0500 Chris Faust
Do you have the latest Apache::DBI ? Ask made a new one a couple of weeks
ago to run with mp2.
On Fri, 14 Feb 2003, Chris Faust wrote:
Hi,
My problem seems like one that would be well documented, but I can't find
anything in any of the docs and even goggle groups only had one message
:[EMAIL PROTECTED]]
Sent: Friday, February 14, 2003 9:26 AM
To: Chris Faust; Modperl
Subject: Re: Apache::DBI and mod_perl 2
Hi Chris,
are you shure that is is the Apache::DBI, that needs the
Apache::Constants
or is it another module?
For me Apache::DBI loads without problems (2.044/1.9908
Subject: Re: Apache::DBI and mod_perl 2
Do you have the latest Apache::DBI ? Ask made a new one a couple of weeks
ago to run with mp2.
On Fri, 14 Feb 2003, Chris Faust wrote:
Hi,
My problem seems like one that would be well documented, but I
can't find
anything in any of the docs
On Fri, 14 Feb 2003, Chris Faust wrote:
Maybe that is the problem?
I'm using 0.89 which is the newest from CPAN and that shows Jun 18..
Is there a later version available?
You can always search the archives of this list at
http://marc.theaimsgroup.com/?l=apache-modperlr=1w=2
The message
Subject: RE: Apache::DBI and mod_perl 2
On Fri, 14 Feb 2003, Chris Faust wrote:
Maybe that is the problem?
I'm using 0.89 which is the newest from CPAN and that shows Jun 18..
Is there a later version available?
You can always search the archives of this list at
http
On Mon, 6 Jan 2003, Paul Simon wrote:
--- Randy Kobes [EMAIL PROTECTED] wrote:
Are you using the latest versions of DBI and
DBD::ODBC?
If not, does an upgrade help?
Those modules are - whatever was bundled with your
first, warmly supplied :), Perl 5.8 + apache2 package
on theoryx5.
Paul Simon wrote:
I wasn't sure if Apache::DBI was screwing with ORACLE,
especially with persistent connections...
The Apache::DBI code is really short and easy to read. Basically, it
just doesn't close connections when you call disconnect. It also does
automatic rollbacks at the end of
Hi Paul -
It is my understanding that Apache::DBI is not yet
implemented for Apache2/mod_perl2. I had to comment
out my references to it in the startup script and/or
the configuration file.
Take a look at:
http://beaucox.com/mason/mason-with-apmp2-mini-HOWTO.htm
for further info.
Aloha =
On Thu, 2 Jan 2003, Paul Simon wrote:
Hi all
I have a feeling this may be [OT], take it to the DBI
list... But I'm hoping to eliminate as much as
possible any suspicion that Apache::DBI/mod_perl is
causing my headache. I'm trying to push this platform
at work ;) If anyone can shed some
On Wed, 20 Nov 2002, Beau E. Cox wrote:
I am using Apache::DBI on my test server - all OK.
When I try to use it on my production server, I get the
following- stdout:
Shutting down httpd..done
Starting httpd [ PERL ]
Syntax OK
stderr:
/etc/init.d/apache: line 206: 18040 Segmentation
-
From: Randy Kobes [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 21, 2002 4:57 AM
To: Beau E. Cox
Cc: Modperl
Subject: Re: Apache::DBI seg fault
On Wed, 20 Nov 2002, Beau E. Cox wrote:
I am using Apache::DBI on my test server - all OK.
When I try to use it on my production server, I get
On Fri, 15 Nov 2002, [iso-8859-1] Faßhauer, Wolfgang, FCI3 wrote:
one database user because of resource limits. The problem I see is that the
password for connecting to the database is clear readable in the perl
script.
Does anybody know how to hide that password?
Have you thought of running
On Fri, 15 Nov 2002, Rafiq Ismail (ADMIN) wrote:
On Fri, 15 Nov 2002, [iso-8859-1] Faßhauer, Wolfgang, FCI3 wrote:
one database user because of resource limits. The problem I see is that the
password for connecting to the database is clear readable in the perl
script.
Does anybody know
Hi there,
On Thu, 17 Oct 2002, John Cameron wrote:
I am finding that the number of open number of database connections I have
open at one time is varying wildly.
Then, Suddenly, the number of connctions jumps up to 50 or more! Sometimes
this falls back to below 20, but sometimes this
Hi,
I am learning lots of new things, but still working on the problem itself.
It seems to be the case that even when I am running under ./httpd -X
I have trouble getting the search query to get stuck. If I do something
from the mysql monitor like set an order on hold directly with a query,
Hi,
I had to read that over a few times to get it. And now I see that I do
indeed have that situation, there are a number of times when I call
my $holdstatus = new Holds(); from within a module that also has a new
method. What I don't understand is how does my code work at all?
Thanks,
Eric
On 15 Oct 2002 at 7:12, Eric Frazier wrote:
I am learning lots of new things, but still working on the problem itself.
It seems to be the case that even when I am running under ./httpd -X I have
trouble getting the search query to get stuck. If I do something from the
mysql monitor like set
I was under the impression that Apache::DBI isn't compatible for this set up:
win2000 + apache2.0.42 + perl5.8 + mod_perl1.99
For a multi threaded environment, isn't Apache::DBIPool necessary? I'd rather use Apache::DBI.
Rafiq Ismail [EMAIL PROTECTED] wrote:
On Tue, 15 Oct 2002, Paul Simon wrote:
Paul Simon wrote:
I was under the impression that Apache::DBI isn't compatible for this
set up:
win2000 + apache2.0.42 + perl5.8 + mod_perl1.99
For a multi threaded environment, isn't Apache::DBIPool necessary? I'd
rather use Apache::DBI.
Apache::DBIPool doesn't actually exist yet.
Eric Frazier wrote:
Here is the kind of thing that is driving me nuts. Please see:
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remed
ies_for_Inner_Subroutines
If what this says is true, then either I don't have a closure type problem,
or else what is says isn't
At 11:58 AM 10/14/02 -0400, Perrin Harkins wrote:
Eric Frazier wrote:
Here is the kind of thing that is driving me nuts. Please see:
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remed
ies_for_Inner_Subroutines
If what this says is true, then either I don't have a
Perrin,
I am starting to feel guilty about bugging you so much, but you are the only
person to have responded, and I watch the list enough to value your advice
quite a bit.
sub new {
my $invocant = shift;
my $class = ref($invocant) || $invocant;
That looks
Eric Frazier wrote:
I wanted the DBH to be global since just about every sub in Holds does a
query of some sort.
Three options:
1) Pass it to every sub
2) Make a utility sub that returns a dbh and call it from each sub.
(Sounds like you already made one of these.)
3) Stuff it in $r-pnotes(),
On Mon, 14 Oct 2002, Eric Frazier wrote:
That looks like voodoo code copied from a man page. If you call this as
Holds-new(), you don't need that junk about ref. (And most people
recommend against the new Holds syntax.)
I wanted the DBH to be global since just about every sub in Holds does
On Mon, 14 Oct 2002, Eric Frazier wrote:
That looks like voodoo code copied from a man page. If you call this as
Holds-new(), you don't need that junk about ref. (And most people
recommend against the new Holds syntax.)
I wanted the DBH to be global since just about every sub in Holds
On 14 Oct 2002 at 9:12, Eric Frazier wrote:
That I am not so sure of. I will do some more investigation. It seems like
the only variables that could be causing this are the result set from the
query and the scalar which holds the html template. I feel like I know
absolutly nothing now :( I
Hey Eric --
I wanted the DBH to be global since just about every sub in Holds does a
query of some sort. I guess it doesn't matter either way if I do
the connect
in the new() vs up top outside of a sub.
CGI::Application has a facility which is intended to solve exactly this type
of problem
Hi,
Here is the kind of thing that is driving me nuts. Please see:
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remed
ies_for_Inner_Subroutines
If what this says is true, then either I don't have a closure type problem,
or else what is says isn't true. It says that
I'm just going to point out a few problems. These are not all related
to your questions.
package Holds;
The case of Holds doesn't match the example sub you posted above. I'm
assuming that was a typo.
use strict;
use Carp;
use warnings;
use QueryPrint;
use vars qw($dbh $processed_hnd
Perrin,
I am going to read over this closely, thanks for all of the advice!
What frustrats me about the search getting cached/closure thing is that I
just don't have any global variables that have anything to do at all with
the search results. I have read over and over examples with closures,
On Tue, 3 Sep 2002 10:36:30 -0700 (PDT)
Anthony E. [EMAIL PROTECTED] wrote:
--- Enrico Sorcinelli [EMAIL PROTECTED]
wrote:
On Tue, 3 Sep 2002 09:05:45 -0700 (PDT)
Anthony E. [EMAIL PROTECTED] wrote:
Hello,
I'm getting an awful lot of these error statements in
my error_log
On Tue, 3 Sep 2002 09:05:45 -0700 (PDT)
Anthony E. [EMAIL PROTECTED] wrote:
Hello,
I'm getting an awful lot of these error statements in
my error_log file for apache:
--
25935 Apache::DBI new connect to
'db:1.2.3.4UserPassAutoCommit=1PrintError=1'
--
It looks like they
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On July 30, 2002 10:02 pm, Stas Bekman wrote:
2) See http://perl.apache.org/docs/2.0/devel/testing/testing.html
Though you can really rely on it once Apache::Test is released, which
will happen when mod_perl 2.0 is released.
1) That's an
Simon Perrault wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On July 30, 2002 10:02 pm, Stas Bekman wrote:
2) See http://perl.apache.org/docs/2.0/devel/testing/testing.html
Though you can really rely on it once Apache::Test is released, which
will happen when mod_perl 2.0 is
Could you please take a look at this problem? Thanks.
- Forwarded message from Stas Bekman [EMAIL PROTECTED] -
Date: Mon, 29 Jul 2002 09:56:05 +0800
From: Stas Bekman [EMAIL PROTECTED]
Reply-To: Stas Bekman [EMAIL PROTECTED]
Subject: Re: Apache::DBI as a prerequisite
Simon Perreault wrote:
You wrote on 2002-04-30 to apache-modperl about Apache::DBI not being testable
while not under mod_perl. You said this:
That's normal. You cannot test modules that use mod_perl API without
running them inside mod_perl server. I've the same problem as you've
reported.
]
To: Zac Morris [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, June 25, 2002 12:26 PM
Subject: Re: Apache::DBI with mod_perl 2.0
Zac Morris wrote:
Ahhh, ok more clarity. :)
Forgive me if I'm just not doing my detective work in poking around for
documentation, but is there a doc
Zac Morris wrote:
Ok, still no luck. Every dependancy has more dependancies all of which go
back and back to mod_perl 1 stuff already being in place
My question is, can I download the Apache 1.3 source (don't make it), then
run the mod_perl 1 build to get all the pm files in place,
Yeah, so I've tried these suggestions:
use Apache2();
use Apache::compat;
and I'm still getting the errors:
Undefined subroutine Apache::Module::loaded called at
/usr/lib/perl5/site_perl/5.6.1/i386-linux/Apache/compat.pm line 95.
Compilation failed in require at ./db_connect_test.pm
Zac Morris wrote:
Yeah, so I've tried these suggestions:
use Apache2();
use Apache::compat;
and I'm still getting the errors:
Undefined subroutine Apache::Module::loaded called at
/usr/lib/perl5/site_perl/5.6.1/i386-linux/Apache/compat.pm line 95.
Compilation failed in
11:02 AM
Subject: Re: Apache::DBI with mod_perl 2.0
Zac Morris wrote:
Yeah, so I've tried these suggestions:
use Apache2();
use Apache::compat;
and I'm still getting the errors:
Undefined subroutine Apache::Module::loaded called at
/usr/lib/perl5/site_perl/5.6.1/i386
Zac Morris wrote:
Ahhh, ok more clarity. :)
Forgive me if I'm just not doing my detective work in poking around for
documentation, but is there a doc that contains all the kludges or
assumed modules I need to already have in place?
All the docs that we have now are at
At 00:49 23.06.2002, Charles Aulds wrote:
At 06:41 PM 6/21/02 +0200, Per Einar Ellefsen ([EMAIL PROTECTED]) wrote:
As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to:
1) make sure you are using the prefork MPM for Apache (as Stas said,
Apache::DBI can only work with that
At 06:41 PM 6/21/02 +0200, Per Einar Ellefsen ([EMAIL PROTECTED])
wrote:
As Apache::DBI hasn't been tested
with mod_perl 2.0 yet, you will need to:
1) make sure you are using the prefork MPM for Apache (as Stas said,
Apache::DBI can only work with that one)
2) You will probably need to run
At 06:41 PM 6/21/02 +0200, Per Einar Ellefsen ([EMAIL PROTECTED])
wrote:
As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will
need to:
1) make sure you are using the prefork MPM for Apache (as Stas
said,
Apache::DBI can only work with that one)
2) You will probably need to run
At 18:26 21.06.2002, Zac Morris wrote:
I actually have a question along these lines
I'm new to mod_perl myself, and I've just installed a new setup with Apache2
and the mod_perl2 beta.
That's all working well and my old cgi-bin type stuff works under mod_perl
great.
Now I'm trying to get
Per Einar Ellefsen wrote:
At 18:26 21.06.2002, Zac Morris wrote:
I actually have a question along these lines
I'm new to mod_perl myself, and I've just installed a new setup with
Apache2
and the mod_perl2 beta.
That's all working well and my old cgi-bin type stuff works under
but first you need:
PerlModule Apache2
or 'use Apache2' in startup.pl. see:
http://perl.apache.org/release/docs/2.0/user/config/config.html#Accessing_the_mod_perl_2_0_Modules
Nope, he did a clean mod_perl 2 install, without MP_INST_APACHE2 I
think... so doesn't have an Apache.pm
At 19:46 21.06.2002, Stas Bekman wrote:
Per Einar Ellefsen wrote:
At 18:26 21.06.2002, Zac Morris wrote:
I actually have a question along these lines
I'm new to mod_perl myself, and I've just installed a new setup with Apache2
and the mod_perl2 beta.
That's all working well and my old
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 that to
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 that to
Gregory Matthews wrote:
Does this mean if each user has to use a unique username/password to
OPEN the database?
Yes, eaxctly.
My prog will use the same database:username:password
for all connection requests opened with a
db_connect($database,$user,$password) call, however, each user
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
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:
Hi!
Thanks a lot for this. I am not sure now if I will be able to use it. I am
afraid that if I do I will suddenly become its main supporter :)
I also still don't see how a connection can be reconnected at such a high
level. Even when I looked into the mySQL C api I didn't see anything that
Eric Frazier wrote:
I also still don't see how a connection can be reconnected at such a high
level.
It can't, unless your database specifically supports the command
reauthenticate. Oracle does, which is what he wrote this for, but I
don't think it's a standard part of SQL syntax so it will
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: This
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 @
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
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
On Fri, 2002-03-22 at 11:42, Andrew Ho wrote:
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
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
We encountered just this situation when we started to move from a win32
application connecting to an RDBMS to a web based app. On the win32
app, the DB authenticated each user with a loginid/pw. Since some users
still use the win32 app, we can't just abandon the DB authentication, so
here's
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
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've seen similar behavior with DBD::Sybase; if your SYBASE env variable
is not set or points at an invalid directory Apache starts up but begins
segging every child process over and over again.
I'm not familiar with Postgres but this might point you in the right
direction.
On Thu, 2002-03-14
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:
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 in
(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 explicitly.
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
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
1 - 100 of 212 matches
Mail list logo
