On Monday 03 December 2007 22:19, David Boyes wrote: > > > 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.
Very interesting. It sounds like something that would be well worth looking at providing we can interface to it from C (or C++) as I imagine is the case. ------------------------------------------------------------------------- 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
