> > > > >Sorry, got my layers inverted > > > You and me both :) And this whole mess I am introducing will fuzz the > layers even more I'm afraid. > > >...SQL::Statement would be the app's interface, > >rather than DBI, per se, yes ? > > > > Umm, no, SQL::Statement is the RDBMS. DBD::CSV, DBD::AnyData, > DBD::Excel etc use it as the underlying engine to parse and evaluate the > SQL. So all of the changes I am suggesting will be available in the > DBDs that use SQL::Statement (though depending on how things work out > some of them may be specific to DBD::AnyData). You can access > SQL::Statement directly without those DBDs though I'm thinking that just > using DBD::AnyData as a front end to it may be easier in some cases. > > One consequence of all this is, one will be able to use, for example > DBD::AnyData to join two XBase tables even though DBD::XBase (the last I > looked) doesn't support joins: > > SELECT * > FROM [EMAIL PROTECTED] > LEFT JOIN [EMAIL PROTECTED]
Yes after my morning walk thru the rolling hills of Reno I realized... One little item, related to your & Mssr. Bunce's thread on the subject, is the ability to replace the explicit DSN used above with a connection identifier...I think this is a DBI level issue (I may have suggested it in the past), basically just adding an Identity attribute to the connection handles. Tho I guess, since DBD::AnyData + SQL::Statement would be handling the connection initation (correct ?), the connection identifier could be assigned there... > > Hopefully I'll have this all sorted out enough to explain it in plain > English at the OSCON BOF. > > -- > Jeff Great, between this topic, Mssr. Bunce's presence, and free beer, we may have SRO! ;^) Dean
