From orsenthil at gmail.com Mon Feb 9 16:43:17 2009 From: orsenthil at gmail.com (Senthil Kumaran) Date: Mon Feb 9 12:13:23 2009 Subject: [egenix-users] Error Msg: 'NoneType' object is not callable" in Hello, I am using mxODBC Connect from a Linux client to a Windows Server and my application uses Storm backend. While I am able to establish the connection and get the operation done, after the completion of the operation I get this error message: Exception exceptions.TypeError: "'NoneType' object is not callable" in >> ignored Can someone help me understand the meaning of this error with respect to mxODBC_Connection class? Here's my setup: I am doing: from mx.ODBCConnect.Client import ServerSession session = ServerSession(self.config_path) mssqldbapi = session.open() And I have mssqldabapi as a global object so that I can import it in a different module. As I am NOT doing a .close() on mssqldbapi, is there any chance of this error coming up? Documentation says that session object is automatically closed when garbage collected and I am see that in stand-alone snippets. But in the scenario, I have described above I am not really sure as why this error message surfaces and the meaning of this error message. Any help appreciated. Thanks, Senthil From mal at egenix.com Mon Feb 9 15:53:40 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 9 15:53:44 2009 Subject: [egenix-users] Error Msg: 'NoneType' object is not callable" in References: <7c42eba10902090313u139ecfc4p70d0f022525cdcbf@mail.gmail.com> Message-ID: <49904374.2080405@egenix.com> On 2009-02-09 12:13, Senthil Kumaran wrote: > Hello, > > I am using mxODBC Connect from a Linux client to a Windows Server and > my application uses Storm backend. > While I am able to establish the connection and get the operation > done, after the completion of the operation I get this error message: > > Exception exceptions.TypeError: "'NoneType' object is not callable" in > id:14560496 meta_info: name:None type_name:'mxODBC Connection'>>> ignored > > Can someone help me understand the meaning of this error with respect > to mxODBC_Connection class? > > Here's my setup: > > I am doing: > > from mx.ODBCConnect.Client import ServerSession > session = ServerSession(self.config_path) > mssqldbapi = session.open() > > And I have mssqldabapi as a global object so that I can import it in a > different module. > > As I am NOT doing a .close() on mssqldbapi, is there any chance of > this error coming up? > Documentation says that session object is automatically closed when > garbage collected and I am see that in stand-alone snippets. > But in the scenario, I have described above I am not really sure as > why this error message surfaces and the meaning of this error message. Given that the above error is triggered in the .__del__() method, it is generated during garbage collection of the connection object and there's obviously an attempt being made at calling an object which was already garbage collected. Are you using multiple threads or a single threaded process and sharing the session object between those ? Do you see any other messages related to this in the client or server log files ? Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 09 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From orsenthil at gmail.com Mon Feb 9 20:50:04 2009 From: orsenthil at gmail.com (Senthil Kumaran) Date: Mon Feb 9 16:20:10 2009 Subject: [egenix-users] Error Msg: 'NoneType' object is not callable" in References: <7c42eba10902090313u139ecfc4p70d0f022525cdcbf@mail.gmail.com> <49904374.2080405@egenix.com> Message-ID: <7c42eba10902090720h55e653f6se9c3698de9709dac@mail.gmail.com> On Mon, Feb 9, 2009 at 8:23 PM, M.-A. Lemburg wrote: > Are you using multiple threads or a single threaded process and > sharing the session object between those ? > Do you see any other messages related to this in the client or > server log files ? Thanks for quick response. I am using a single threaded process and sharing the session object between the processes. I see the following in the Server log files when that error occurs: Time Stamp: : Protocol error: lost connection And another information worth mentioning here would be, even though mine is a single process, after a n number of COMPLETED tests/execution of the snippet, I get: InterfaceError: Connection limit exceeded. Your license allows 20 physical database connections. At that point, I go to the Server and restart the Connect Server to proceed with my client code implementation/testing again. What is actually happening here? Why is the Connection limit error message coming for script executions one after the other? Thanks, Senthil From orsenthil at gmail.com Mon Feb 9 21:17:33 2009 From: orsenthil at gmail.com (Senthil Kumaran) Date: Mon Feb 9 16:47:39 2009 Subject: [egenix-users] Exception exceptions.AttributeError - Depending upon the naming of the module ( connector.py / error_connector.py) Message-ID: <7c42eba10902090747x8d75877n142c9a8d61d9a348@mail.gmail.com> Hello, This is a strange issue which is occurring with how I name a particular module. Is this anyway related to namespace pollution?If yes, can some more details/ information be shared? I am going to present the snippets in-line (as they are very short) and show you the test conditions. Case 1: Working Case # test_mxconnect.py from global_connector import initialize_connector CONFIG_PATH = '/usr/local/etc/client-config.ini' CONNECTION_STRING = 'DSN=jiva_trunk;UID=jiva_user;PWD=jiva_user' if __name__ == '__main__': initialize_connector(connector_name='mxOdbcConnect', client_config_path = CONFIG_PATH) from global_connector import MsSQLdbapi if not hasattr(MsSQLdbapi, 'connect'): db_api = MsSQLdbapi.open() print MsSQLdbapi, db_api ------------------------------------------------------------------------------------------------------------------------------------- #global_connector.py def initialize_connector (connector_name='mxODBC', **kwargs): global MsSQLdbapi try: if connector_name == 'mxODBC': pass elif connector_name == 'mxOdbcConnect': from mx.ODBCConnect.Client import ServerSession config_path = kwargs.get('client_config_path') if not config_path: raise AssertionError, "Expected keyword arg: client_config_path" MsSQLdbapi = ServerSession(config_path) except ImportError,e: print e raise ---------------------------------------------------------------------------------------------------------------- Case 2: Do a $mv global_connector.py connector.py And in test_mxconnect.py, replace global_connector with connector.py # test_mxconnect.py from connector import initialize_connector # Offender in the module name CONFIG_PATH = '/usr/local/etc/client-config.ini' CONNECTION_STRING = 'DSN=jiva_trunk;UID=jiva_user;PWD=jiva_user' if __name__ == '__main__': initialize_connector(connector_name='mxOdbcConnect', client_config_path = CONFIG_PATH) from connector import MsSQLdbapi # Offender in the module name if not hasattr(MsSQLdbapi, 'connect'): db_api = MsSQLdbapi.open() print MsSQLdbapi, db_api The Error message, I get after script execution is: Exception exceptions.AttributeError: "'NoneType' object has no attribute 'EndOfCommunicationRequestObject'" in >> ignored Case 3: Failure Scenario. If I name the module global_connector.py as error_connector.py, and use that in the test_mxconnect.py, I still get the error Exception at the end of completion of the script. Any explanations? -- -- Senthil From mal at egenix.com Mon Feb 9 23:08:44 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 9 23:08:48 2009 Subject: [egenix-users] Exception exceptions.AttributeError - Depending upon the naming of the module ( connector.py / error_connector.py) In-Reply-To: <7c42eba10902090747x8d75877n142c9a8d61d9a348@mail.gmail.com> References: <7c42eba10902090747x8d75877n142c9a8d61d9a348@mail.gmail.com> Message-ID: <4990A96C.5080008@egenix.com> On 2009-02-09 16:47, Senthil Kumaran wrote: > Hello, > > This is a strange issue which is occurring with how I name a particular module. > Is this anyway related to namespace pollution?If yes, can some more > details/ information be shared? This doesn't have anything to do with the naming.. well at least not directly. The problem with your approach is that you're using a module global to store the session object. At interpreter exit time, Python will clear all modules, but the order in which this happens is undefined (in CPython it depends on the order of the items in the module dictionary at the time of exit, but that's an implementation detail of CPython). As a result, depending on how you name the module holding the session object reference, it may get cleared before or after the other modules using it. Once the It is better to keep globals such as the session object in a context object that you pass around in your application code as parameter to the various methods/functions. Note that it's also better to explicitly close the session object once you're done with the server communication. Not doing this can lead to a situation where Python has already cleared out part of the mxODBC Connect package modules while still keeping a reference to the session object. Once this object is cleared as well, it will try to close to session and this can then very likely fail due to only half of the functions, classes and objects used by mxODBC Connect still being in existence at that time. Please note that this is true for any larger Python application or package, not just mxODBC Connect. > I am going to present the snippets in-line (as they are very short) > and show you the test conditions. > > Case 1: Working Case > > # test_mxconnect.py > from global_connector import initialize_connector > > CONFIG_PATH = '/usr/local/etc/client-config.ini' > CONNECTION_STRING = 'DSN=jiva_trunk;UID=jiva_user;PWD=jiva_user' > > if __name__ == '__main__': > initialize_connector(connector_name='mxOdbcConnect', > client_config_path = CONFIG_PATH) > from global_connector import MsSQLdbapi > if not hasattr(MsSQLdbapi, 'connect'): > db_api = MsSQLdbapi.open() > print MsSQLdbapi, db_api > > ------------------------------------------------------------------------------------------------------------------------------------- > #global_connector.py > def initialize_connector (connector_name='mxODBC', **kwargs): > global MsSQLdbapi > try: > if connector_name == 'mxODBC': > pass > elif connector_name == 'mxOdbcConnect': > from mx.ODBCConnect.Client import ServerSession > config_path = kwargs.get('client_config_path') > if not config_path: > raise AssertionError, "Expected keyword arg: client_config_path" > MsSQLdbapi = ServerSession(config_path) > except ImportError,e: > print e > raise > ---------------------------------------------------------------------------------------------------------------- > > Case 2: > Do a $mv global_connector.py connector.py > And in test_mxconnect.py, replace global_connector with connector.py > > # test_mxconnect.py > from connector import initialize_connector # Offender in the module name > > CONFIG_PATH = '/usr/local/etc/client-config.ini' > CONNECTION_STRING = 'DSN=jiva_trunk;UID=jiva_user;PWD=jiva_user' > > if __name__ == '__main__': > initialize_connector(connector_name='mxOdbcConnect', > client_config_path = CONFIG_PATH) > from connector import MsSQLdbapi # Offender in the module name > if not hasattr(MsSQLdbapi, 'connect'): > db_api = MsSQLdbapi.open() > print MsSQLdbapi, db_api > > > The Error message, I get after script execution is: > > Exception exceptions.AttributeError: "'NoneType' object has no > attribute 'EndOfCommunicationRequestObject'" in ServerSession.close of >> ignored > > Case 3: Failure Scenario. > > If I name the module global_connector.py as error_connector.py, and > use that in the test_mxconnect.py, I still get the error Exception at > the end of completion of the script. > > > Any explanations? > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 09 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From mal at egenix.com Mon Feb 9 23:13:16 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 9 23:13:20 2009 Subject: [egenix-users] Error Msg: 'NoneType' object is not callable" in References: <7c42eba10902090313u139ecfc4p70d0f022525cdcbf@mail.gmail.com> <49904374.2080405@egenix.com> <7c42eba10902090720h55e653f6se9c3698de9709dac@mail.gmail.com> Message-ID: <4990AA7C.6010000@egenix.com> On 2009-02-09 16:20, Senthil Kumaran wrote: > On Mon, Feb 9, 2009 at 8:23 PM, M.-A. Lemburg wrote: >> Are you using multiple threads or a single threaded process and >> sharing the session object between those ? >> Do you see any other messages related to this in the client or >> server log files ? > > Thanks for quick response. > > I am using a single threaded process and sharing the session object > between the processes. > I see the following in the Server log files when that error occurs: > > Time Stamp: : Protocol error: lost connection > > And another information worth mentioning here would be, even though > mine is a single process, after a n number of COMPLETED > tests/execution of the snippet, I get: > > InterfaceError: Connection limit exceeded. Your license allows 20 > physical database connections. > > At that point, I go to the Server and restart the Connect Server to > proceed with my client code implementation/testing again. > > What is actually happening here? Why is the Connection limit error > message coming for script executions one after the other? See my other reply. The above cases are also side-effects of using a module global for storing the session objects or connections. If you don't close the connections you are using explicitly they may well still be kept alive by some reference to the connection object in your application. The server will only shutdown the real connection to the database if it sees a .close() method call from the client side (or finds a timeout). While you can rely on the fact that the conneection object deallocation will implicitly close the connection, you do have to be careful about how you manage references to the connection object. Otherwise, the connections are not closed when you think they should be closed. "Explicit is better than implicit" :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 09 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From mal at egenix.com Tue Feb 10 11:48:45 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 10 11:48:48 2009 Subject: [egenix-users] installation successful? In-Reply-To: References: <49785437.8070109@egenix.com> <4979A0BF.3020505@egenix.com> <4981E495.6010106@egenix.com> Message-ID: <49915B8D.3030103@egenix.com> On 2009-02-10 03:43, Tentin Quarantino wrote: > Hi, > > Yes, I installed the updated software. It works for me. Thank you for > addressing so promptly. You are awesome! :) Thanks :-) > Cheers! > > >>> It turns out that the solution to the problem requires some changes >>> to the way we restore the pre-built information during the installation. >>> >>> We will release a new version of egenix-mx-base to address this. >> The new release 3.1.2 should solve the issue you saw on Mac OS X >> with the pre-built release. >> -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 10 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From egenix at jf-gosset.com Tue Feb 10 17:17:17 2009 From: egenix at jf-gosset.com (egenix@jf-gosset.com) Date: Tue Feb 10 17:17:25 2009 Subject: [egenix-users] mx.DateTime.now()accuracy Message-ID: <5.1.1.6.0.20090210171056.00c16650@wheresmymailserver.com> With the old 2.0.3 version of mx.DateTime, now() returned fraction of seconds so we had 1/100sec accuracy. With 3.1.2 version, now() now [!] returns whole integer numbers. Tested with same version of Python (2.5.4). Just switched mx... package in site-packages Is it by design or is it a bug? Thank's jf From mal at egenix.com Tue Feb 10 17:29:13 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 10 17:29:16 2009 Subject: [egenix-users] mx.DateTime.now()accuracy In-Reply-To: <5.1.1.6.0.20090210171056.00c16650@wheresmymailserver.com> References: <5.1.1.6.0.20090210171056.00c16650@wheresmymailserver.com> Message-ID: <4991AB59.8010703@egenix.com> On 2009-02-10 17:17, egenix@jf-gosset.com wrote: > With the old 2.0.3 version of mx.DateTime, now() returned fraction of seconds so we had 1/100sec accuracy. > With 3.1.2 version, now() now [!] returns whole integer numbers. > > Tested with same version of Python (2.5.4). Just switched mx... package in site-packages > > Is it by design or is it a bug? On which platform are you seeing this problem ? mxDateTime does return fractions on Linux: >>> from mx.DateTime import now >>> now() -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 10 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From egenix at jf-gosset.com Tue Feb 10 17:41:01 2009 From: egenix at jf-gosset.com (egenix@jf-gosset.com) Date: Tue Feb 10 17:41:06 2009 Subject: [egenix-users] mx.DateTime.now()accuracy In-Reply-To: <4991AB59.8010703@egenix.com> References: <5.1.1.6.0.20090210171056.00c16650@wheresmymailserver.com> <5.1.1.6.0.20090210171056.00c16650@wheresmymailserver.com> Message-ID: <5.1.1.6.0.20090210173750.00c26148@127.0.0.1> Hi, That's on Windows platform (tested with 2.5.1 and 2.5.4 versions of python). Thank's jf Message d'origine (10/02/2009 17:29) ?mis par (M.-A. Lemburg) : >On 2009-02-10 17:17, egenix@jf-gosset.com wrote: >> With the old 2.0.3 version of mx.DateTime, now() returned fraction of seconds so we had 1/100sec accuracy. >> With 3.1.2 version, now() now [!] returns whole integer numbers. >> >> Tested with same version of Python (2.5.4). Just switched mx... package in site-packages >> >> Is it by design or is it a bug? > >On which platform are you seeing this problem ? > >mxDateTime does return fractions on Linux: > >>>> from mx.DateTime import now >>>> now() > > >-- >Marc-Andre Lemburg >eGenix.com > >Professional Python Services directly from the Source (#1, Feb 10 2009) >>>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ >________________________________________________________________________ > >::: Try our new mxODBC.Connect Python Database Interface for free ! :::: > > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ From mal at egenix.com Tue Feb 10 18:00:19 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 10 18:00:23 2009 Subject: [egenix-users] mx.DateTime.now()accuracy In-Reply-To: <5.1.1.6.0.20090210173750.00c26148@127.0.0.1> References: <5.1.1.6.0.20090210171056.00c16650@wheresmymailserver.com> <5.1.1.6.0.20090210171056.00c16650@wheresmymailserver.com> <5.1.1.6.0.20090210173750.00c26148@127.0.0.1> Message-ID: <4991B2A3.3060903@egenix.com> On 2009-02-10 17:41, egenix@jf-gosset.com wrote: > Hi, > > That's on Windows platform (tested with 2.5.1 and 2.5.4 versions of python). In mxDateTime 3.x we're using a more direct way of getting the current time which is faster. Apparently, on Windows this doesn't provide the full accuracy anymore. We'll add a fix for this to the next eGenix mx Base release. As work-around you can comment out the following line in egenix_mx_base.py of the distribution to have mxDateTime use the 2.x strategy again: #define_macros=[('USE_FAST_GETCURRENTTIME', None)], Some more context: mx_Extension('mx.DateTime.mxDateTime.mxDateTime', ['mx/DateTime/mxDateTime/mxDateTime.c'], # If mxDateTime doesn't compile, try removing the next line. #define_macros=[('USE_FAST_GETCURRENTTIME', None)], # include_dirs=['mx/DateTime/mxDateTime'], optional_libraries=_mxDateTime_optional_libraries, ), You'll then have to recompile the package using python setup.py bdist_msi and install the generated MSI file. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 10 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ > Thank's > jf > > Message d'origine (10/02/2009 17:29) ?mis par (M.-A. Lemburg) : >> On 2009-02-10 17:17, egenix@jf-gosset.com wrote: >>> With the old 2.0.3 version of mx.DateTime, now() returned fraction of seconds so we had 1/100sec accuracy. >>> With 3.1.2 version, now() now [!] returns whole integer numbers. >>> >>> Tested with same version of Python (2.5.4). Just switched mx... package in site-packages >>> >>> Is it by design or is it a bug? >> On which platform are you seeing this problem ? >> >> mxDateTime does return fractions on Linux: >> >>>>> from mx.DateTime import now >>>>> now() >> >> >> -- >> Marc-Andre Lemburg >> eGenix.com >> >> Professional Python Services directly from the Source (#1, Feb 10 2009) >>>>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ >> ________________________________________________________________________ >> >> ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: >> >> >> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >> Registered at Amtsgericht Duesseldorf: HRB 46611 >> http://www.egenix.com/company/contact/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > https://www.egenix.com/mailman/listinfo/egenix-users From tentin.quarantino at gmail.com Tue Feb 10 12:28:21 2009 From: tentin.quarantino at gmail.com (Tentin Quarantino) Date: Tue Feb 10 21:28:25 2009 Subject: [egenix-users] help making data source on Unix Message-ID: Hello, I thought it best to try the mxODBC driver on Windows because the file I wanted to read/query was from Windows environment. It is a Microsoft ".mdb" file. The data source string (what's the proper name for this?) which I used is the following: driver = 'DRIVER={Microsoft Access Driver (*.mdb)};DBQ=c:/databases/sample/BFDsystem.mdb;PWD=secret' I was successful, to query the mdb file: BFDsystem.mdb However, I need to run this python program on Unix. Is it possible to read this "mdb" file from Unix host and file system? And if so, what is the data source config string? I am thinking this will not be possible due to special sauce on Windows machine. Cheers and many thanks for advice! From egenix at jf-gosset.com Tue Feb 10 21:40:54 2009 From: egenix at jf-gosset.com (egenix@jf-gosset.com) Date: Tue Feb 10 21:41:18 2009 Subject: [egenix-users] mx.DateTime.now()accuracy Message-ID: <5.1.1.6.0.20090210214010.020b44d8@127.0.0.1> I don't have a compiler installed (I used the binary installer). I will install one if you want a feedback, otherwise I think that I can, actually, live with 2.0.3 version. Thank's a lot for your rapid answer and your explanations. jf gosset Message d'origine (10/02/2009 18:00) : >On 2009-02-10 17:41, egenix@jf-gosset.com wrote: >> Hi, >> >> That's on Windows platform (tested with 2.5.1 and 2.5.4 versions of python). > >In mxDateTime 3.x we're using a more direct way of getting the >current time which is faster. Apparently, on Windows this doesn't >provide the full accuracy anymore. > >We'll add a fix for this to the next eGenix mx Base release. > >As work-around you can comment out the following line in egenix_mx_base.py >of the distribution to have mxDateTime use the 2.x strategy again: > > #define_macros=[('USE_FAST_GETCURRENTTIME', None)], > >Some more context: > > mx_Extension('mx.DateTime.mxDateTime.mxDateTime', > ['mx/DateTime/mxDateTime/mxDateTime.c'], > # If mxDateTime doesn't compile, try removing the next line. > #define_macros=[('USE_FAST_GETCURRENTTIME', None)], > # > include_dirs=['mx/DateTime/mxDateTime'], > optional_libraries=_mxDateTime_optional_libraries, > ), > >You'll then have to recompile the package using > >python setup.py bdist_msi > >and install the generated MSI file. > >Thanks, >-- >Marc-Andre Lemburg >eGenix.com > >Professional Python Services directly from the Source (#1, Feb 10 2009) >>>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ >________________________________________________________________________ > >::: Try our new mxODBC.Connect Python Database Interface for free ! :::: > > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ > >> Thank's >> jf >> >> Message d'origine (10/02/2009 17:29) ?mis par (M.-A. Lemburg) : >>> On 2009-02-10 17:17, egenix@jf-gosset.com wrote: >>>> With the old 2.0.3 version of mx.DateTime, now() returned fraction of seconds so we had 1/100sec accuracy. >>>> With 3.1.2 version, now() now [!] returns whole integer numbers. >>>> >>>> Tested with same version of Python (2.5.4). Just switched mx... package in site-packages >>>> >>>> Is it by design or is it a bug? >>> On which platform are you seeing this problem ? >>> >>> mxDateTime does return fractions on Linux: >>> >>>>>> from mx.DateTime import now >>>>>> now() >>> >>> >>> -- >>> Marc-Andre Lemburg >>> eGenix.com >>> >>> Professional Python Services directly from the Source (#1, Feb 10 2009) >>>>>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>>>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>>>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ >>> ________________________________________________________________________ >>> >>> ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: >>> >>> >>> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >>> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >>> Registered at Amtsgericht Duesseldorf: HRB 46611 >>> http://www.egenix.com/company/contact/ >> >> >> _______________________________________________________________________ >> eGenix.com User Mailing List http://www.egenix.com/ >> https://www.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Tue Feb 10 21:47:16 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 10 21:47:21 2009 Subject: [egenix-users] help making data source on Unix In-Reply-To: References: Message-ID: <4991E7D4.6080209@egenix.com> On 2009-02-10 21:28, Tentin Quarantino wrote: > Hello, > > I thought it best to try the mxODBC driver on Windows because the file > I wanted to read/query was from Windows environment. It is a Microsoft > ".mdb" file. > > The data source string (what's the proper name for this?) which I used > is the following: > > driver = 'DRIVER={Microsoft Access Driver > (*.mdb)};DBQ=c:/databases/sample/BFDsystem.mdb;PWD=secret' > > I was successful, to query the mdb file: BFDsystem.mdb > > However, I need to run this python program on Unix. Is it possible to > read this "mdb" file from Unix host and file system? And if so, what > is the data source config string? I am thinking this will not be > possible due to special sauce on Windows machine. If you want to use the MS ODBC driver for this, you will have to redirect the work to a Windows machine, e.g. run the Python program on Linux and use mxODBC Connect to connect to the Windows box and run your queries there. The Windows box will have to get access to the .mdb file for this to work. Another possibility is trying to read the .mdb file directly on Linux using e.g. MDBTools (http://freshmeat.net/projects/mdbtools/). They provide a simple ODBC driver which you can hook up to mxODBC to read the files. However, that project has never reached a stable release and doesn't look like it's being maintained. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 10 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From mal at egenix.com Tue Feb 10 22:42:37 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 10 22:42:44 2009 Subject: [egenix-users] mx.DateTime.now()accuracy In-Reply-To: <5.1.1.6.0.20090210211745.00c26148@127.0.0.1> References: <5.1.1.6.0.20090210173750.00c26148@127.0.0.1> <5.1.1.6.0.20090210171056.00c16650@wheresmymailserver.com> <5.1.1.6.0.20090210171056.00c16650@wheresmymailserver.com> <5.1.1.6.0.20090210173750.00c26148@127.0.0.1> <5.1.1.6.0.20090210211745.00c26148@127.0.0.1> Message-ID: <4991F4CD.9010809@egenix.com> On 2009-02-10 21:27, Jean-Fran?ois Gosset wrote: > I don't have a compiler installed (I used the binary installer). > I will install one if you want a feedback, otherwise I think that I can, actually, live with 2.0.3 version. > > Thank's a lot for your rapid answer and your explanations. I've uploaded a snapshot installer which includes our current fix: http://downloads.egenix.com/python/egenix-mx-base-3.1.3_20090210.win32-py2.6.msi http://downloads.egenix.com/python/egenix-mx-base-3.1.3_20090210.win32-py2.6.msi Please give them a go. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 10 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ > jf gosset > > Message d'origine (10/02/2009 18:00) : >> On 2009-02-10 17:41, egenix@jf-gosset.com wrote: >>> Hi, >>> >>> That's on Windows platform (tested with 2.5.1 and 2.5.4 versions of python). >> In mxDateTime 3.x we're using a more direct way of getting the >> current time which is faster. Apparently, on Windows this doesn't >> provide the full accuracy anymore. >> >> We'll add a fix for this to the next eGenix mx Base release. >> >> As work-around you can comment out the following line in egenix_mx_base.py >> of the distribution to have mxDateTime use the 2.x strategy again: >> >> #define_macros=[('USE_FAST_GETCURRENTTIME', None)], >> >> Some more context: >> >> mx_Extension('mx.DateTime.mxDateTime.mxDateTime', >> ['mx/DateTime/mxDateTime/mxDateTime.c'], >> # If mxDateTime doesn't compile, try removing the next line. >> #define_macros=[('USE_FAST_GETCURRENTTIME', None)], >> # >> include_dirs=['mx/DateTime/mxDateTime'], >> optional_libraries=_mxDateTime_optional_libraries, >> ), >> >> You'll then have to recompile the package using >> >> python setup.py bdist_msi >> >> and install the generated MSI file. >> >> Thanks, >> -- >> Marc-Andre Lemburg >> eGenix.com >> >> Professional Python Services directly from the Source (#1, Feb 10 2009) >>>>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ >> ________________________________________________________________________ >> >> ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: >> >> >> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >> Registered at Amtsgericht Duesseldorf: HRB 46611 >> http://www.egenix.com/company/contact/ >> >>> Thank's >>> jf >>> >>> Message d'origine (10/02/2009 17:29) ?mis par (M.-A. Lemburg) : >>>> On 2009-02-10 17:17, egenix@jf-gosset.com wrote: >>>>> With the old 2.0.3 version of mx.DateTime, now() returned fraction of seconds so we had 1/100sec accuracy. >>>>> With 3.1.2 version, now() now [!] returns whole integer numbers. >>>>> >>>>> Tested with same version of Python (2.5.4). Just switched mx... package in site-packages >>>>> >>>>> Is it by design or is it a bug? >>>> On which platform are you seeing this problem ? >>>> >>>> mxDateTime does return fractions on Linux: >>>> >>>>>>> from mx.DateTime import now >>>>>>> now() >>>> >>>> >>>> -- >>>> Marc-Andre Lemburg >>>> eGenix.com >>>> >>>> Professional Python Services directly from the Source (#1, Feb 10 2009) >>>>>>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>>>>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>>>>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ >>>> ________________________________________________________________________ >>>> >>>> ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: >>>> >>>> >>>> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >>>> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >>>> Registered at Amtsgericht Duesseldorf: HRB 46611 >>>> http://www.egenix.com/company/contact/ >>> >>> _______________________________________________________________________ >>> eGenix.com User Mailing List http://www.egenix.com/ >>> https://www.egenix.com/mailman/listinfo/egenix-users From tentin.quarantino at gmail.com Tue Feb 10 14:44:45 2009 From: tentin.quarantino at gmail.com (Tentin Quarantino) Date: Tue Feb 10 23:44:49 2009 Subject: [egenix-users] help making data source on Unix In-Reply-To: <4991E7D4.6080209@egenix.com> References: <4991E7D4.6080209@egenix.com> Message-ID: If there is method to make: >> driver = 'DRIVER={Microsoft Access Driver >> (*.mdb)};DBQ=c:/databases/sample/BFDsystem.mdb;PWD=secret' a service via network interface on the Windows box, then that would be great. Then I could use mxODBC to connect over the network. I like it! :) May I ask on this list for terms to google about enabling such a service (port?) on Windows OS? I will consult the mxODBC docs to determine how the driver config string will change. Many thanks! From egenix at jf-gosset.com Tue Feb 10 23:43:17 2009 From: egenix at jf-gosset.com (egenix@jf-gosset.com) Date: Tue Feb 10 23:44:53 2009 Subject: [egenix-users] mx.DateTime.now()accuracy In-Reply-To: <4991F4CD.9010809@egenix.com> References: <5.1.1.6.0.20090210211745.00c26148@127.0.0.1> <5.1.1.6.0.20090210173750.00c26148@127.0.0.1> <5.1.1.6.0.20090210171056.00c16650@wheresmymailserver.com> <5.1.1.6.0.20090210171056.00c16650@wheresmymailserver.com> <5.1.1.6.0.20090210173750.00c26148@127.0.0.1> <5.1.1.6.0.20090210211745.00c26148@127.0.0.1> Message-ID: <5.1.1.6.0.20090210233847.00c26148@127.0.0.1> >> I don't have a compiler installed (I used the binary installer). >> I will install one if you want a feedback, otherwise I think that I can, actually, live with 2.0.3 version. >> >> Thank's a lot for your rapid answer and your explanations. > >I've uploaded a snapshot installer which includes our current fix: > >http://downloads.egenix.com/python/egenix-mx-base-3.1.3_20090210.win32-py2.6.msi py2.5: http://downloads.egenix.com/python/egenix-mx-base-3.1.3_20090210.win32-py2.5.msi >http://downloads.egenix.com/python/egenix-mx-base-3.1.3_20090210.win32-py2.6.msi > >Please give them a go. That's OK. Thank's!! jf From orsenthil at gmail.com Wed Feb 11 17:44:41 2009 From: orsenthil at gmail.com (Senthil Kumaran) Date: Wed Feb 11 13:14:47 2009 Subject: [egenix-users] Exception exceptions.AttributeError - Depending upon the naming of the module ( connector.py / error_connector.py) In-Reply-To: <4990A96C.5080008@egenix.com> References: <7c42eba10902090747x8d75877n142c9a8d61d9a348@mail.gmail.com> <4990A96C.5080008@egenix.com> Message-ID: <7c42eba10902110414ke6a0538i5b400f536813076d@mail.gmail.com> On Tue, Feb 10, 2009 at 3:38 AM, M.-A. Lemburg wrote: > At interpreter exit time, Python will clear all modules, but the > order in which this happens is undefined (in CPython it depends on > the order of the items in the module dictionary at the time of exit, > but that's an implementation detail of CPython). Thanks for the explanation, Marc. That helped. > It is better to keep globals such as the session object in > a context object that you pass around in your application > code as parameter to the various methods/functions. If I understand it properly, you recommend: class A: def __init__(): ... self.connection = DriverConnect() ... objA = A() And call stormedDB = StormifyDatabase(objA) If I have mis-understood. can you please point me to any example snippets which I can look at and design accordingly. > Note that it's also better to explicitly close the session > object once you're done with the server communication. I would like to do that, the but the point is: user_script.py - has db_api = Now, I pass this object to storm ORM and the entire application uses the stormified object. Returns the value. I have tried doing .close() on __del__() method of the class where I am opening the ClientSideObject, but still after a "couple of successful executions" (without any error message in the Server.log) I end up at: File "mx/ODBCConnect/Common/ProxyObjects.py", line 675, in __call__ File "mx/ODBCConnect/Client/ServerSession.py", line 614, in methodcall File "mx/ODBCConnect/Client/ServerSession.py", line 423, in _response File "mx/ODBCConnect/Common/ProxyObjects.py", line 1191, in process_response InterfaceError: Connection limit exceeded. Your license allows 20 physical database connections. called from the very same __del__() method. I might share the code at support@egenix.com for further suggestions. Thank you, Senthil -- -- Senthil From mal at egenix.com Wed Feb 11 14:24:33 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 11 14:24:38 2009 Subject: [egenix-users] Exception exceptions.AttributeError - Depending upon the naming of the module ( connector.py / error_connector.py) In-Reply-To: <7c42eba10902110414ke6a0538i5b400f536813076d@mail.gmail.com> References: <7c42eba10902090747x8d75877n142c9a8d61d9a348@mail.gmail.com> <4990A96C.5080008@egenix.com> <7c42eba10902110414ke6a0538i5b400f536813076d@mail.gmail.com> Message-ID: <4992D191.9030109@egenix.com> On 2009-02-11 13:14, Senthil Kumaran wrote: > On Tue, Feb 10, 2009 at 3:38 AM, M.-A. Lemburg wrote: >> At interpreter exit time, Python will clear all modules, but the >> order in which this happens is undefined (in CPython it depends on >> the order of the items in the module dictionary at the time of exit, >> but that's an implementation detail of CPython). > > Thanks for the explanation, Marc. That helped. > >> It is better to keep globals such as the session object in >> a context object that you pass around in your application >> code as parameter to the various methods/functions. > > If I understand it properly, you recommend: > > class A: > > def __init__(): > ... > self.connection = DriverConnect() > ... > > objA = A() > > And call > > stormedDB = StormifyDatabase(objA) > > > If I have mis-understood. can you please point me to any example > snippets which I can look at and design accordingly. Well, it's a little more complicated than that and requires a change in the application design: It is better to store all non-constant global variables in a context object. Depending on the type of application, this can be dynamically created in a request handler or the apps startup code. You then add all global objects needed for processing the request to this context object and pass it around as parameter when calling functions or methods, e.g. def main(): # Startup context = MyContext() context.connection = DriverConnect() # Processing do_something(context) # Finalization context.connection.close() >> Note that it's also better to explicitly close the session >> object once you're done with the server communication. > > I would like to do that, the but the point is: > > user_script.py - has db_api = > Now, I pass this object to storm ORM and the entire application uses > the stormified object. Returns the value. This db_api object is the module object you get from the session object, right ? Here's a typical example of how you'd use mxODBC Connect: from mx.ODBCConnect.Client import ServerSession def main(): # Setup a server session session = ServerSession(config_file='client-config.ini') # Connect to the mxODBC Connect Server db_api = session.open() # Connect to a database connection = db_api.DriverConnect('DSN=...;UID=...;PWD=...') # Process data on the connection ... # Finalize the connection connection.close() # Finalize the server session session.close() Note that there are no module global being used. This assures that you have controlled garbage collection. > I have tried doing .close() on __del__() method of the class where I > am opening the ClientSideObject, but still after a "couple of > successful executions" (without any error message in the Server.log) > I end up at: > File "mx/ODBCConnect/Common/ProxyObjects.py", line 675, in __call__ > File "mx/ODBCConnect/Client/ServerSession.py", line 614, in methodcall > File "mx/ODBCConnect/Client/ServerSession.py", line 423, in _response > File "mx/ODBCConnect/Common/ProxyObjects.py", line 1191, in process_response > InterfaceError: Connection limit exceeded. Your license allows 20 > physical database connections. > > called from the very same __del__() method. Are you running the requests in a for-loop or starting the script 20 or more times ? > I might share the code at support@egenix.com for further suggestions. Ok, please send some example code to support. We can then see whether we need to add special support for your use case to mxODBC Connect or whether there's another way to achieve what you want. In any case, we'll make the session object .close() method more robust, so that it doesn't cause random exception when called during the Python shutdown process. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 11 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From orsenthil at gmail.com Wed Feb 11 21:28:53 2009 From: orsenthil at gmail.com (Senthil Kumaran) Date: Wed Feb 11 16:58:59 2009 Subject: [egenix-users] Exception exceptions.AttributeError - Depending upon the naming of the module ( connector.py / error_connector.py) In-Reply-To: <4992D191.9030109@egenix.com> References: <7c42eba10902090747x8d75877n142c9a8d61d9a348@mail.gmail.com> <4990A96C.5080008@egenix.com> <7c42eba10902110414ke6a0538i5b400f536813076d@mail.gmail.com> <4992D191.9030109@egenix.com> Message-ID: <7c42eba10902110758m3d5d6153i69dcc5c18d6fd779@mail.gmail.com> Thanks for the quick response again. I shall try all your suggestions. I was not aware the connection.close() and session.close() should be done. I was just doing connection.close() On Wed, M.-A. Lemburg wrote: > Are you running the requests in a for-loop or starting the script > 20 or more times ? I am starting and running the script for 6-7 times, one after the after and this error message comes up. I wonder what is happening, because the python interpretor is shutdown each time the script is complete ( successfully for 6-7 times). I go restart the server and the same pattern will follow. Thanks, Senthil -- -- Senthil From mal at egenix.com Wed Feb 11 17:22:44 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 11 17:22:47 2009 Subject: [egenix-users] Exception exceptions.AttributeError - Depending upon the naming of the module ( connector.py / error_connector.py) In-Reply-To: <7c42eba10902110758m3d5d6153i69dcc5c18d6fd779@mail.gmail.com> References: <7c42eba10902090747x8d75877n142c9a8d61d9a348@mail.gmail.com> <4990A96C.5080008@egenix.com> <7c42eba10902110414ke6a0538i5b400f536813076d@mail.gmail.com> <4992D191.9030109@egenix.com> <7c42eba10902110758m3d5d6153i69dcc5c18d6fd779@mail.gmail.com> Message-ID: <4992FB54.9080702@egenix.com> On 2009-02-11 16:58, Senthil Kumaran wrote: > Thanks for the quick response again. I shall try all your suggestions. > I was not aware the connection.close() and session.close() should be > done. I was just doing connection.close() > > On Wed, M.-A. Lemburg wrote: >> Are you running the requests in a for-loop or starting the script >> 20 or more times ? > > I am starting and running the script for 6-7 times, one after the > after and this error message comes up. > I wonder what is happening, because the python interpretor is shutdown > each time the script is complete ( successfully for 6-7 times). I go > restart the server and the same pattern will follow. That would explain why you are running out of connections. If you don't call session.close() on the client side and the implicit call fails due to Python already having shut down modules which are needed to communicate the end-of-communication to the server, the server will only notice the closed client connection after a timeout is reached. The server will keep the database connections open until it gets the timeout notice. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 11 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From mal at egenix.com Wed Feb 11 18:29:19 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 11 18:29:24 2009 Subject: [egenix-users] Exception exceptions.AttributeError - Depending upon the naming of the module ( connector.py / error_connector.py) In-Reply-To: <4992D191.9030109@egenix.com> References: <7c42eba10902090747x8d75877n142c9a8d61d9a348@mail.gmail.com> <4990A96C.5080008@egenix.com> <7c42eba10902110414ke6a0538i5b400f536813076d@mail.gmail.com> <4992D191.9030109@egenix.com> Message-ID: <49930AEF.1000408@egenix.com> On 2009-02-11 14:24, M.-A. Lemburg wrote: > On 2009-02-11 13:14, Senthil Kumaran wrote: > Here's a typical example of how you'd use mxODBC Connect: > > from mx.ODBCConnect.Client import ServerSession > > def main(): > > # Setup a server session > session = ServerSession(config_file='client-config.ini') > > # Connect to the mxODBC Connect Server > db_api = session.open() > > # Connect to a database > connection = db_api.DriverConnect('DSN=...;UID=...;PWD=...') > > # Process data on the connection > ... > > # Finalize the connection > connection.close() > > # Finalize the server session > session.close() > > Note that there are no module global being used. This assures that > you have controlled garbage collection. Here's an easy fix for the situation where you have the session object defined as module global: # Register atexit function import atexit atexit.register(session.close) Such exit functions are called at Python shutdown time, but just before the interpreter gets finalized, ie. all modules are still available, so all the connections of the session get closed properly. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 11 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From orsenthil at gmail.com Thu Feb 19 14:48:35 2009 From: orsenthil at gmail.com (Senthil Kumaran) Date: Thu Feb 19 10:18:41 2009 Subject: [egenix-users] Error Msg: 'NoneType' object is not callable" in References: <7c42eba10902090313u139ecfc4p70d0f022525cdcbf@mail.gmail.com> <49904374.2080405@egenix.com> <7c42eba10902090720h55e653f6se9c3698de9709dac@mail.gmail.com> <4990AA7C.6010000@egenix.com> Message-ID: <7c42eba10902190118g18610467t3694af597f7116a4@mail.gmail.com> On Tue, Feb 10, 2009 at 3:43 AM, M.-A. Lemburg wrote: > The server will only > shutdown the real connection to the database if it sees > a .close() method call from the client side (or finds a > timeout). > > While you can rely on the fact that the conneection > object deallocation will implicitly close the connection, > you do have to be careful about how you manage references > to the connection object. Otherwise, the connections are > not closed when you think they should be closed. Just to make sure that I don't forget to inform you. The Documentation on the mxODBC Connect does not mention the need of explicit close of session and connection objects. I think, this can be improved in the mxODBC Connect Documentation. Thanks, Senthil From mal at egenix.com Thu Feb 19 10:42:29 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 19 10:42:35 2009 Subject: [egenix-users] Error Msg: 'NoneType' object is not callable" in References: <7c42eba10902090313u139ecfc4p70d0f022525cdcbf@mail.gmail.com> <49904374.2080405@egenix.com> <7c42eba10902090720h55e653f6se9c3698de9709dac@mail.gmail.com> <4990AA7C.6010000@egenix.com> <7c42eba10902190118g18610467t3694af597f7116a4@mail.gmail.com> Message-ID: <499D2985.6070304@egenix.com> On 2009-02-19 10:18, Senthil Kumaran wrote: > On Tue, Feb 10, 2009 at 3:43 AM, M.-A. Lemburg wrote: >> The server will only >> shutdown the real connection to the database if it sees >> a .close() method call from the client side (or finds a >> timeout). >> >> While you can rely on the fact that the conneection >> object deallocation will implicitly close the connection, >> you do have to be careful about how you manage references >> to the connection object. Otherwise, the connections are >> not closed when you think they should be closed. > > Just to make sure that I don't forget to inform you. > The Documentation on the mxODBC Connect does not mention the need of > explicit close of session and connection objects. I think, this can be > improved in the mxODBC Connect Documentation. Yes. We'll add more information about this to the 1.0.1 release which will also include the changes we have already sent you in private email to make the client and server more robust in situations where the client side modules are in process of being shutdown and it's possible that the final message doesn't make it through to the server. The new release is scheduled for next week. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 19 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From jeff.fincher at verizonbusiness.com Thu Feb 26 18:12:16 2009 From: jeff.fincher at verizonbusiness.com (Jeff Fincher) Date: Fri Feb 27 01:12:31 2009 Subject: [egenix-users] Unix Plone to MSSQL Message-ID: <1235693536.29516.145.camel@localhost.localdomain> I am running Zope/Plone 3.2.1 on RHEL and want to connect to MS SQL on a another server. I purchased mxODBC to do this job. Now I am wondering, is mxODBC a DA that will let me do that or do I need additional components? It seems that mxODBC will talk to iODBC which in turn will talk to a driver like unixODBC or FreeTDS that will finally talk to the MS SQL server. Is that right? Or is there a shorter path? Thanks, -Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20090226/362fea38/attachment.htm From charlie at egenix.com Fri Feb 27 18:54:28 2009 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 27 18:54:32 2009 Subject: [egenix-users] Unix Plone to MSSQL In-Reply-To: <1235693536.29516.145.camel@localhost.localdomain> References: <1235693536.29516.145.camel@localhost.localdomain> Message-ID: Am 27.02.2009, 01:12 Uhr, schrieb Jeff Fincher : > I am running Zope/Plone 3.2.1 on RHEL and want to connect to MS SQL on a > another server. I purchased mxODBC to do this job. Now I am wondering, > is mxODBC a DA that will let me do that or do I need additional > components? >It seems that mxODBC > will talk to iODBC which in turn > will talk to a driver like unixODBC or FreeTDS > that will finally talk to the MS SQL server. Hi Jeff, that is indeed the standard procedure. We do, however, offer mxODBC Connect for just this kind of scenario. This involves installing a server component on the Windows machine and a client component on the Zope machine. The two components communicate in pure Python and handle all networking issues so we hope that this setup is not only easier to maintain but also faster and more reliable. There, is currently no Zope DA for this so you would have to handle connections yourself from Python code in Zope. There will soon be a buildout recipe that supports this configuration. Charlie -- Charlie Clark eGenix.com Professional Python Services directly from the Source >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/