On Wednesday, August 31, 2011 02:28:39 pm Ed Leafe wrote: > On Aug 31, 2011, at 3:50 PM, John Fabiani wrote: > > Rather than attempt to create a universal dbODBC.py where I attempt to > > deal with each database unique requirements, i.e. data types, getting > > the last insert PK, limits, etc.. This would be a match to what we are > > currently doing for each of the supported databases (postgres, mssql, > > mysql) currently. > > Let's keep it simple first. Go with a generic dbODBC.py, and make it > specific to MSSQL. Once that's working, see what would be involved in > adding support for VFP (or some other ODBC backend). If there is more > involved than handling a few differences in code it might be good to get > more granular than that, but we'll still need an ODBC superclass to handle > the common code, which is what we're doing with the other servers you > mention. We have the dBackend class that holds all the common behavior, > and when a specific backend deviates from that, we break that code into > the subclass for that server type. > > > > -- Ed Leafe
I have completed an ODBC script for MsSQL and it appears to work well so far. Combining Roger's code and the current dbMsSQL worked well. I hand coded the form I used for testing. At the moment I have hard coded the connection string. So I think I'm ready to move forward. I'm looking at the CxnEditor next. I think it would be a snap to add panel to provide the required fields for the ODBC connection string. It would match the basic layout we have now but of course change the field labels to match the MsSQL connection string requirements. The only issue I have in mind at the moment is how to handle when only a DSN string/name is provided. BTW I'm doing all of this on Windows. Johnf _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev Searchable Archives: http://leafe.com/archives/search/dabo-dev This message: http://leafe.com/archives/byMID/[email protected]
