> *This message was transferred with a trial version of CommuniGate(tm) Pro* > > >From: "Oscar L. Garz�n" <[EMAIL PROTECTED]> > >To: "Sergio Gonz�lez" <[EMAIL PROTECTED]> > >Subject: Dynamic DBSource > >Date: Tue, 28 Jan 2003 05:10:03 -0500 > >X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) > >Importance: Normal > > > >What would be the best way to implement dynamic dbsource specifications > >based on run-time variables, what I actually need is what the following > >sentence says, but as you my guess, the do not work because sql > >connections are handled at startup. ( %R would be realm ) > > > >DBSource DBI:Pg:dbname=%R > >DBUsername %R
Not sure I can help you if you need a different user/server, but logging to different databases on the same system should be fairly trivial; simply construct your SQL statements as UPDATE %R.tablename SET ... or similar. If you need to be using different logins entirely, possibly some sort of proxying system would be your best answer (there's a DBI-based one you might be able to use since you're running Perl already) - so a single apparent login and db server to Radiator becomes multiple on the other side. I don't think you'd really want to do this otherwise anyway, since setting up and tearing down your database connection every time you have a hit is horrifically expensive - probably more so than the proxying solution described above. OR - the unpleasant but ultimately perhaps the simplest way - knock up a quick script that generates a separate clause for each potential Realm. - Matt S Trout === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
