> > Sounds like it might be smarter to implement a Bacula interface to the > > Perl DBI:: package interface, and then the problem is permanently > > solved, and not just for DB/2, but for just about any useful database > > that currently exists. That would give us Oracle, Ingres, DB/2, Sybase, > > etc w/o imposing other restrictions. There would be some restrictions on > > what SQL statements can be fed to the DBI interface, but Bacula doesn't > > do anything that fancy, so the restrictions would be fairly minor, IMHO. > > I am a bit skeptical about OBDC since all the good DBAs that I know tell > me > that it doesn't really work as it should.
Perl DBI is not ODBC. It's a set of wrapper functions that allow database-independent code to be written, with the actual database used being selected at runtime by configuring the DBI interface code. Database vendors supply drop-in back-ends (some open, some not), but no code linkage occurs that is not open. ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
