I hope this interests the developers Spend a good 2-day run trying to figure these out and thought I share(rant about it) :)
My dev environment is as follows: Windows XP (also allegedly works in Win7) MS SQL 2008 Express python 2.6.6 pymssql 1.0.2 (pre-compiled from installer) latest wx and dabo These are my remarks: - pymssql 1.9.9.x still has the nasty freeze all bug. It can be still worked around by importing pymssql first thing in your code. Still, it doesn't work out of the box with dabo (works fine by itself though) and the fact that the pymssql module is now a .pyx --> .pyd file makes patching for dabo problematic if you don't have a build environment in Windows. So I did stick with pymssql 1.0.2 and python 2.6.6. - pymssql's 1.0.2 driver from the installer is built against msvcr71.dll and mscvp71.dll. Be sure you have these if you get a DLL error on import. - The only working (almost as a whole, see remarks) patches for me were JacekK's patches from ticket #1375 http://trac.dabodev.com/ticket/1375 which I'd like to break down: pymssql.py.patch: This is the only thing needed here as this fixes all the dabo "pymssqlCnx doesn't have XXX attribute" errors. Works like a charm but I'm still troubled that it might override some useful properties, like their new self.connection (untested though) dbMsSQL.py.patch: chunk 1 (regarding port usage) - #if not port or port == "None": - #port = 1433 - #host = "%s:%s" % (connectInfo.Host, port) - host = connectInfo.Host + if not port or port == "None": + port = 1433 + host = "%s:%s" % (connectInfo.Host, port) This is problematic for me and I left it out of my code. Reasoning is this: Most of the time, at least with SQL Express 2008, you reference your connection as a (in lack of proper terminology) file descriptor like .\SQLEXPRESS or WINSERVER\SQLEXPRESS In fact, SQL 2008 doesn't really use ports by default. So, existing dabo code (disregarding port altogether) works, and even if you wanted to insert a port in there, my hunch is that you'd want something like example.com:1334\SQLEXPRESS but that's not something I can test, and other versions of SQL might behave differently. "None" however is a good option to have for port because of the above, even if the existing behavior changes. chunk 2 (regarding self.connection) - return self.__source + return self._source This is good form as ._source internally returns .__source but checks for a closed connection and returns an exception otherwise. Used as is. My thoughts are that we'd might want to catch an exception if it'd occured, but I didn't find a test case for that with dabo. It should be noted that perhaps this is now unneeded as 1.0.2 connections have a .connection property. Still, since we patched pymssql.py to expose the internals, I'm unsure if the .connection property is still accessible. Frankly, it works and I stuck with it. chunk 3 (regading casting Decimal to int) - return crs.getFieldVal("newid") + idVal = crs.getFieldVal("newid") + if isinstance(idVal, Decimal): + idVal = int(idVal) + return idVal This is perhaps the most crucial chunk in the patch and the one I don't have a clue about why/how it works. My only remark here is that maybe you should check if the MSSQL types that translate to Decimal have a more general flaw and should be updated, instead of just overriding the behavior for idVal. Feel free to cross post in dabo-users or the wiki if you think this should be in there too. If you have some easy test cases I'd be willing to test them against my current XP/SQLEXPRESS 2008 setup, although I admit that now it works for me I'm less interested (until something more breaks, hehe). Maybe I can help close those long-standing bugs. Thanks for your time reading this, Nick _______________________________________________ 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]
