From william.jones12 at wilkes.edu Thu Mar 1 10:44:55 2007 From: william.jones12 at wilkes.edu (Jones, William) Date: Thu Mar 1 16:45:04 2007 Subject: [egenix-users] Error message opening connection using WinXP ODBC connection to Access file on network drive In-Reply-To: References: Message-ID: <0F302422C7813E44A3F4263270CE91D3435CEF@EXCHVS2.wilkesu.wilkes.edu> Hello, I'm trying to set up an Access database on a network drive that I can connect to using mxODBC. The database connector works fine in Zope when I have the database on the client machine, but when I move it over to a network drive I get an error message: *** Connection string: DSN=GSCL_non_credit_registration Connection pool entry: 0 Error message: ('HY024', -1023, "[Microsoft][ODBC Microsoft Access Driver] '(unknown)' is not a valid path. Make sure that the path name is spelled correctly and that you are connected to the server on which the file resides.", 8227) *** The WinXP ODBC dialog allows me to find the database file on the network just fine. I put the file in the root of my personal network drive so the path is as simple as possible with no spaces, and I checked the path in command prompt to make sure it worked. The path was: h:\GSCL_non_credit_registration_db.mbd I also opened up the ODBC connection in an Excel spreadsheet and imported a table to make sure the Windows ODBC was working ok. So, I'm pretty sure that it's the database connector that's having a problem with a file on a network drive. Much thanks, Bill J. *************************************************************** William R. Jones, M.A., M.S. Max Roth Center 208 Director, Life-Long Learning ph: (570) 408-4462 william.jones12@wilkes.edu fax: (570) 408-7846 Wilkes University * 84 W. South Street * Wilkes-Barre, PA 18766 *************************************************************** From charlie at egenix.com Thu Mar 1 16:55:17 2007 From: charlie at egenix.com (Charlie Clark) Date: Thu Mar 1 16:55:35 2007 Subject: [egenix-users] Error message opening connection using WinXP ODBC connection to Access file on network drive In-Reply-To: <0F302422C7813E44A3F4263270CE91D3435CEF@EXCHVS2.wilkesu.wilkes.edu> References: <0F302422C7813E44A3F4263270CE91D3435CEF@EXCHVS2.wilkesu.wilkes.edu> Message-ID: Am 01.03.2007, 16:44 Uhr, schrieb Jones, William : > Hello, > I'm trying to set up an Access database on a network drive that I can > connect to using mxODBC. The database connector works fine in Zope when > I have the database on the client machine, but when I move it over to a > network drive I get an error message: Dear Mr. Jones, Microsoft Access can be very difficult to, er, access on a network - there are a number of articles on Microsoft's website that cover the topic but another common error is that the user under which Zope is running may not have access to the DSN but in your case The path was: h:\GSCL_non_credit_registration_db.mbd From memory someone else had a similar issue a while back and I think the thing is that you cannot use mapped drives but have to have the full network path. I think the articles on Microsoft's website cover this in greater detail. Charlie From david.krosel at maxxian.com Tue Mar 6 09:57:40 2007 From: david.krosel at maxxian.com (David Krosel) Date: Tue Mar 6 15:57:53 2007 Subject: [egenix-users] mxODBC Zope DA and Linux Zope -- Connections not being disconnected References: <013001c72066$e3df1730$0101a8c0@maxdk1> <458857E8.9010305@egenix.com> Message-ID: <00f101c75fff$cb626170$6801a8c0@maxdk1> Hello all, Even under very low load, Zope runs out of connections after about 30 days and the next database request ends in a db-error. I need to restart Zope each time. I only have 1-2 users per day using the system. My configuration is as follows: ------------------------------ mxODBC Zope DA 1.0.10 Zope 2.7.7 Pool size = 21 Number Zope threads = 21 Linux Centos 4.3 The ODBC is configured for: ----------------------------- MySql 4.1.x on the local server Threading=0 Thanks in advance. Regards, David ----- Original Message ----- From: "M.-A. Lemburg" To: "David Krosel" Cc: Sent: Tuesday, December 19, 2006 4:21 PM Subject: Re: [egenix-users] mxODBC Zope DA and Linux Zope -- pooling not increasing > On 2006-12-15 17:34, David Krosel wrote: >> Hello, >> >> Under stress testing running 20 web clients concurrently, the number of >> "Physical connections" doesn't go higher than "1". By observations, it is >> clear that multiple requests are pending since only one connection is >> open to the database. >> >> My configuration is as follows: >> >> mxODBC Zope DA 1.0.10 >> Zope 2.7.7 >> Pool size = 21 >> Number Zope threads = 21 >> Linux Centos 4.3 >> >> The ODBC is configured for a local MySql 4.1.x >> >> Can you help? > > Do you see any error messages in the log file or the shell > (when running Zope manually from the command line) ? > > It is possible that the ODBC driver doesn't allow multiple > connections to the database for some reason. > > Which ODBC manager are you using ? > > If it's unixODBC, then you might be experiencing the following > problem with unixODBC: > > """ > When using mxODBC Zope DA with the unixODBC ODBC manager providing > the connection to the ODBC driver, Zope appears to hang whenever a > long running query is initiated on one of the Zope connections. > > This is due to the unixODBC manager applying a very restrictive > thread isolation protection which basically serializes all requests > to the drivers on a per process scope. > > For references, have a look at these links: > > http://www.unixodbc.org/odbcinst.html > http://archives.postgresql.org/pgsql-odbc/2004-03/msg00060.php > > These are the available unixODBC Thread Levels (taken from the > __handle.c file of unixODBC): > > * Level 0 - Only the DM internal structures are protected > * the driver is assumed to take care of it's self > * > * Level 1 - The driver is protected down to the statement level > * each statement will be protected, and the same for the connect > * level for connect functions, note that descriptors are considered > * equal to statements when it comes to thread protection. > * > * Level 2 - The driver is protected at the connection level. only > * one thread can be in a particular driver at one time > * > * Level 3 - The driver is protected at the env level, only one thing > * at a time. > * > * By default the driver open connections with a lock level of 3, > * this can be changed by adding the line > * > * Threading = N > * > * to the driver entry in odbcinst.ini, where N is the locking level > * (0-3) > > Fortunately, the fix is easy: just add the line > > Threading = 0 > > to the section in odbcinst.ini for the driver you are > using, e.g. > > [PostgreSQL] > Description = PostgreSQL driver for Linux & Win32 > Driver = /usr/local/lib/libodbcpsql.so > Setup = /usr/local/lib/libodbcpsqlS.so > Threading = 0 > > Note that "Threading = 0" is normally only allowed for ODBC drivers > which are fully multi-threaded, however, since the mxODBC Zope DA > already provides the necessary thread protection at the connection > level, you can get some added performance by disabling the additional > protection in the unixODBC manager. > > The iODBC manager does not seem to have this problem. So this > is a second alternative to solve the problem. > """ > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Dec 19 2006) >>>> 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Tue Mar 6 16:09:11 2007 From: charlie at egenix.com (Charlie Clark) Date: Tue Mar 6 16:09:15 2007 Subject: [egenix-users] mxODBC Zope DA and Linux Zope -- Connections not being disconnected In-Reply-To: <00f101c75fff$cb626170$6801a8c0@maxdk1> References: <013001c72066$e3df1730$0101a8c0@maxdk1> <458857E8.9010305@egenix.com> <00f101c75fff$cb626170$6801a8c0@maxdk1> Message-ID: Am 06.03.2007, 15:57 Uhr, schrieb David Krosel : > Hello all, > Even under very low load, Zope runs out of connections after about 30 > days and the next database request ends in a db-error. I need to restart > Zope each time. I only have 1-2 users per day using the system. > My configuration is as follows: > ------------------------------ > mxODBC Zope DA 1.0.10 > Zope 2.7.7 > Pool size = 21 > Number Zope threads = 21 > Linux Centos 4.3 > The ODBC is configured for: > ----------------------------- > MySql 4.1.x on the local server > Threading=0 A pool size of 21 and 21 Zope threads seems excessive. Why have you gone for such a high number? We really need the full traceback of the error as we do not expect it to be in mxODBC. Have you run an ODBC trace? Charlie From david.krosel at maxxian.com Tue Mar 6 10:22:18 2007 From: david.krosel at maxxian.com (David Krosel) Date: Tue Mar 6 16:22:25 2007 Subject: [egenix-users] mxODBC Zope DA and Linux Zope -- Connections not being disconnected References: <013001c72066$e3df1730$0101a8c0@maxdk1> <458857E8.9010305@egenix.com> <00f101c75fff$cb626170$6801a8c0@maxdk1> Message-ID: <010301c76003$3b1eef80$6801a8c0@maxdk1> Hello, 21? I thought I would try for a high and safe number :) When the problem occurs again, I will provide a snap-shot, but I couldn't find any errors in the Zope log. Under the Zope mxODBC configuration screen, there is a note that "Under heavy load, closing the connection may not result in the physical connections to get freed. This is due to the multi-threaded nature of Zope." Can this be related to my problem, even without the load? Regards, David ----- Original Message ----- From: "Charlie Clark" To: "David Krosel" ; Sent: Tuesday, March 06, 2007 10:09 AM Subject: Re: [egenix-users] mxODBC Zope DA and Linux Zope -- Connections not being disconnected Am 06.03.2007, 15:57 Uhr, schrieb David Krosel : > Hello all, > Even under very low load, Zope runs out of connections after about 30 > days and the next database request ends in a db-error. I need to restart > Zope each time. I only have 1-2 users per day using the system. > My configuration is as follows: > ------------------------------ > mxODBC Zope DA 1.0.10 > Zope 2.7.7 > Pool size = 21 > Number Zope threads = 21 > Linux Centos 4.3 > The ODBC is configured for: > ----------------------------- > MySql 4.1.x on the local server > Threading=0 A pool size of 21 and 21 Zope threads seems excessive. Why have you gone for such a high number? We really need the full traceback of the error as we do not expect it to be in mxODBC. Have you run an ODBC trace? Charlie From charlie at egenix.com Tue Mar 6 16:32:42 2007 From: charlie at egenix.com (Charlie Clark) Date: Tue Mar 6 16:32:46 2007 Subject: [egenix-users] mxODBC Zope DA and Linux Zope -- Connections not being disconnected In-Reply-To: <010301c76003$3b1eef80$6801a8c0@maxdk1> References: <013001c72066$e3df1730$0101a8c0@maxdk1> <458857E8.9010305@egenix.com> <00f101c75fff$cb626170$6801a8c0@maxdk1> <010301c76003$3b1eef80$6801a8c0@maxdk1> Message-ID: Am 06.03.2007, 16:22 Uhr, schrieb David Krosel : > Hello, > 21? I thought I would try for a high and safe number When the problem > occurs again, I will provide a snap-shot, but I couldn't find any errors > in the Zope log. You should also check the unixODBC and MySQL logs. > Under the Zope mxODBC configuration screen, there is a note that "Under > heavy load, closing the connection may not result in the physical > connections to get freed. This is due to the multi-threaded nature of > Zope." > Can this be related to my problem, even without the load? No but if you are in fact not running under heavy load there is probably not a need for a lot of threads. Please try running Zope and mxODBC with default values as this may help identify the problem. Charlie From peter at fry-it.com Tue Mar 6 16:33:56 2007 From: peter at fry-it.com (Peter Bengtsson) Date: Tue Mar 6 17:34:03 2007 Subject: [egenix-users] Stored procedure call not happening Message-ID: <45ED97F4.7000207@fry-it.com> Hi, I've got a stored procedure called prcVisionTest which takes one parameter. It looks like this:: CREATE PROCEDURE dbo.prcVisionTest (@fullname as varchar(50), @returnMessage varchar(100) output) as insert into appuser (fullname,datalocationid,departmentid) values (@fullname,1000,3030) set @returnMessage='Record updated' GO I tried call it like this:: >>> c.callproc("prcVisionTest", ["abc123"]) ['abc123'] >>> c.execute("select * from appuser where fullname='abc123'") >>> print c.fetchone() None We looked at some Profiler program for MS SQL which allegedly notices all SQL coming in to the server and we found nothing. Clearly the driver doesn't send the stored procedure call. Why? Peter PS. We use Linux 32-bit mxODBC version '2.1.0' over FreeTDS. DNS is defined like this:: [VAUKLive_Dev] Driver = FreeTDS Description = Connecting to VAUKLive_dev Trace = No Server = 172.24.66.6 Database = Vision_staff_profiles Pooling = No -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com From charlie at egenix.com Tue Mar 6 20:31:18 2007 From: charlie at egenix.com (Charlie Clark) Date: Tue Mar 6 20:31:21 2007 Subject: [egenix-users] Stored procedure call not happening In-Reply-To: <45ED97F4.7000207@fry-it.com> References: <45ED97F4.7000207@fry-it.com> Message-ID: Am 06.03.2007, 17:33 Uhr, schrieb Peter Bengtsson : > Hi, > I've got a stored procedure called prcVisionTest which takes one > parameter. It looks like this:: > CREATE PROCEDURE dbo.prcVisionTest > (@fullname as varchar(50), @returnMessage varchar(100) output) > as > insert into appuser (fullname,datalocationid,departmentid) values > (@fullname,1000,3030) > set @returnMessage='Record updated' > GO > I tried call it like this:: > >>> c.callproc("prcVisionTest", ["abc123"]) > ['abc123'] > >>> c.execute("select * from appuser where fullname='abc123'") > >>> print c.fetchone() > None > We looked at some Profiler program for MS SQL which allegedly notices > all SQL coming in to the server and we found nothing. > Clearly the driver doesn't send the stored procedure call. Why? Please see section 2.3.6 in the mxODBC manual. Charlie From programmer at paradigm-corp.com Tue Mar 6 14:35:01 2007 From: programmer at paradigm-corp.com (Programmer) Date: Tue Mar 6 20:35:09 2007 Subject: [egenix-users] String or binary data would be truncated Message-ID: <611B913B025B1B4494E40781B4F6A61C01A425AF@SERVER.paradigm-corp.com> Here's the trace: Traceback (innermost last): * Module ZPublisher.Publish, line 115, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 41, in call_object * Module OFS.DTMLMethod, line 144, in __call__ URL: http://localhost:8080/ds/diesResponse/manage_main Physical Path:/ds/diesResponse * Module DocumentTemplate.DT_String, line 476, in __call__ * Module DocumentTemplate.DT_Try, line 140, in render * Module DocumentTemplate.DT_Try, line 149, in render_try_except * Module DocumentTemplate.DT_Util, line 196, in eval __traceback_info__: fileList * Module , line 1, in * Module Shared.DC.Scripts.Bindings, line 311, in __call__ * Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec * Module Products.PythonScripts.PythonScript, line 325, in _exec * Module None, line 7, in dieFiles Line 7 * Module Shared.DC.ZRDB.DA, line 495, in __call__ * Module Products.mxODBCZopeDA.ZopeDA, line 1503, in query * Module Products.mxODBCZopeDA.ZopeDA, line 1366, in run_cursor_callback * Module Products.mxODBCZopeDA.ZopeDA, line 1502, in * Module Products.mxODBCZopeDA.ZopeDA, line 999, in errorhandler Warning: ('22001', 8152, '[Microsoft][ODBC SQL Server Driver][SQL Server]String or binary data would be truncated.', 6113) Here is the script dieFiles: parameters = files, dieID sqlMethod = context.addDieFiles f = str(files).split(',') if files is not None: for j in f: sqlMethod(ID=dieID, fname=str(j)) The form allows the user to select a single file for the "order form". This filename goes into the Dies table. At the bottom of the form the user can select several files for "art work" and these filenames are then inserted into the dieFiles table which is FKed to the Dies table. In my tests the insert is successful if I choose an order form and not an art work file. I thought I was having one of those Zope errors due to the format of the values. These look as such: order_form value - 'C:\\Documents and Settings\\Programmer\\My Documents\\Code\\blinkingBox.txt' fileList value with one file selected - 'C:\\Documents and Settings\\Programmer\\My Documents\\Code\\copyFields.txt' fileList value with multiple files - ['C:\\Documents and Settings\\Programmer\\My Documents\\Code\\caveman.txt', 'C:\\Documents and Settings\\Programmer\\My Documents\\Code\\CATEGORY.txt'] As you can see the fileList value with one file selected is the same as from order_form which does insert successfully on it's own. What gives here? Is this a freak of nature? A SQL Server hiccup? my sloppy code? or mxODBCZopeDA.ZopeDA? help! Zope 2.9.6 Python 2.4.3 XP Pro mxODBCZopeDA-1.0.10 SQL Server 2K M. A. Ruberto (Programmer) Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20070306/4d28999a/attachment.htm From support at egenix.com Tue Mar 6 22:59:06 2007 From: support at egenix.com (eGenix Support) Date: Tue Mar 6 22:59:20 2007 Subject: [egenix-users] String or binary data would be truncated In-Reply-To: <611B913B025B1B4494E40781B4F6A61C01A425AF@SERVER.paradigm-corp.com> References: <611B913B025B1B4494E40781B4F6A61C01A425AF@SERVER.paradigm-corp.com> Message-ID: Am 06.03.2007, 20:35 Uhr, schrieb Programmer : > Warning: ('22001', 8152, '[Microsoft][ODBC SQL Server Driver][SQL > Server]String or binary data would be truncated.', 6113) The key here is that the error message is coming from the MS SQL server. It looks to me like one of the parameters is longer than a defined field and is, thus, correctly rejected by the database. > Here is the script dieFiles: > parameters = files, dieID > sqlMethod = context.addDieFiles > f = str(files).split(',')if files is not None: > for j in f: > sqlMethod(ID=dieID, fname=str(j)) Eek! That's worse than some of the stuff I come up with! ;-) You can use the :list suffix on a form variable name to ensure you get a list. Or you can also use the same_type() (or something like this) call in a PythonScript to determine whether you have a list. Either of these will tidy up your code meaning less throwaway varibales that can bite in the future. if not same_type([], files): files = list(files) for f in files: sqlMethod(ID=dieID, fname=f) > The form allows the user to select a single file for the "order form". > This filename goes into the Dies table. At the bottom of the form the > user can select several files for "art work" and these filenames are > then inserted into the dieFiles table which is FKed to the Dies table. > In my tests the insert is successful if I choose an order form and not > an art work file. I thought I was having one of those Zope errors due to > the format of the values. These look as such: > order_form value - 'C:\\Documents and Settings\\Programmer\\My > Documents\\Code\\blinkingBox.txt' > fileList value with one file selected - 'C:\\Documents and > Settings\\Programmer\\My Documents\\Code\\copyFields.txt' > fileList value with multiple files - ['C:\\Documents and > Settings\\Programmer\\My Documents\\Code\\caveman.txt', 'C:\\Documents > and Settings\\Programmer\\My Documents\\Code\\CATEGORY.txt'] > As you can see the fileList value with one file selected is the same as > from order_form which does insert successfully on it's own. What gives > here? > Is this a freak of nature? A SQL Server hiccup? my sloppy code? or > mxODBCZopeDA.ZopeDA? help! You should check the SQL logs to see exactly which value is causing the problem. 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 mxODBC.Zope.DA for Windows, Mac OS, Linux, Solaris, FreeBSD for free! From programmer at paradigm-corp.com Wed Mar 7 13:50:17 2007 From: programmer at paradigm-corp.com (Programmer) Date: Wed Mar 7 19:50:31 2007 Subject: [egenix-users] String or binary data would be truncated Message-ID: <611B913B025B1B4494E40781B4F6A61C01A42625@SERVER.paradigm-corp.com> Charlie, I fixed it. Seems I just needed to force the variable back to the top of the namespace from the page calling the dieFiles method. It's the last place I thought to look! I can't say exactly why it wasn't being found in the namespace though. The Zope namespace reminds me of the Twilight Zone sometimes. Thanks! Mike -----Original Message----- From: eGenix Support [mailto:support@egenix.com] Sent: Tuesday, March 06, 2007 4:59 PM To: Programmer; egenix-users@egenix.com Cc: support@egenix.com Subject: Re: [egenix-users] String or binary data would be truncated Am 06.03.2007, 20:35 Uhr, schrieb Programmer : > Warning: ('22001', 8152, '[Microsoft][ODBC SQL Server Driver][SQL > Server]String or binary data would be truncated.', 6113) The key here is that the error message is coming from the MS SQL server. It looks to me like one of the parameters is longer than a defined field and is, thus, correctly rejected by the database. > Here is the script dieFiles: > parameters = files, dieID > sqlMethod = context.addDieFiles > f = str(files).split(',')if files is not None: > for j in f: > sqlMethod(ID=dieID, fname=str(j)) Eek! That's worse than some of the stuff I come up with! ;-) You can use the :list suffix on a form variable name to ensure you get a list. Or you can also use the same_type() (or something like this) call in a PythonScript to determine whether you have a list. Either of these will tidy up your code meaning less throwaway varibales that can bite in the future. if not same_type([], files): files = list(files) for f in files: sqlMethod(ID=dieID, fname=f) > The form allows the user to select a single file for the "order form". > This filename goes into the Dies table. At the bottom of the form the > user can select several files for "art work" and these filenames are > then inserted into the dieFiles table which is FKed to the Dies table. > In my tests the insert is successful if I choose an order form and not > an art work file. I thought I was having one of those Zope errors due > to the format of the values. These look as such: > order_form value - 'C:\\Documents and Settings\\Programmer\\My > Documents\\Code\\blinkingBox.txt' > fileList value with one file selected - 'C:\\Documents and > Settings\\Programmer\\My Documents\\Code\\copyFields.txt' > fileList value with multiple files - ['C:\\Documents and > Settings\\Programmer\\My Documents\\Code\\caveman.txt', 'C:\\Documents > and Settings\\Programmer\\My Documents\\Code\\CATEGORY.txt'] As you > can see the fileList value with one file selected is the same as from > order_form which does insert successfully on it's own. What gives > here? > Is this a freak of nature? A SQL Server hiccup? my sloppy code? or > mxODBCZopeDA.ZopeDA? help! You should check the SQL logs to see exactly which value is causing the problem. 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 mxODBC.Zope.DA for Windows, Mac OS, Linux, Solaris, FreeBSD for free! From fabiorizzo at gmail.com Wed Mar 7 17:37:57 2007 From: fabiorizzo at gmail.com (Fabio Rizzo Matos) Date: Wed Mar 7 21:38:05 2007 Subject: [egenix-users] Calling Stored Procedures Message-ID: Hi all, It's correct to call stored procedures: def geranavtreepai(self, idseq, dsn, user, password): conn = mxODBC.connect(dsn=dsn,user=user,password=password) cur = conn.cursor() try: cur.callproc('PROC_GERANAVTREE_PAI',(idseq,)) cur.execute("""SELECT caso, codsolicitacaopai, nrdocumentopai, nrgrupai, codsituacaoworkflowpai AS situacaopai, codsolicitacaofilho, nrdocumentofilho, nrgrufilho, codsituacaoworkflowfilho AS situacaofilho, codsolicitacaoneto, nrdocumentoneto, nrgruneto, codsituacaoworkflowneto AS situacaoneto, codanexo, descricaoanexo, abreviacao, assuntopai, indicativoresultado, r.descricao FROM TEMP_NAVTREE t, solicitacao s, tipoobjeto o, ramificacao r WHERE s.codtipoobjeto = o.codtipoobjeto AND s.datainiciovigencia = o.datainiciovigencia AND o.codramificacao = r.codramificacao AND o.codassuntoprincipal = r.codassuntoprincipal AND o.codassunto = r.codassunto AND s.codsolicitacao = t.codsolicitacaopai ORDER BY 3, 2, 6, 10""") rs = cur.fetchall() conn.commit() conn.close() except: return None return rs My awnsers is too slow.... This maybe caused for my way to call the procedure? Thanks in advance! -- Fabio Rizzo ThreePointsWeb fabiorizzo@threepointsweb.com ---- -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20070307/ca39e7f9/attachment.htm From support at egenix.com Wed Mar 7 23:04:54 2007 From: support at egenix.com (eGenix Support) Date: Wed Mar 7 23:05:09 2007 Subject: [egenix-users] Calling Stored Procedures In-Reply-To: References: Message-ID: Am 07.03.2007, 21:37 Uhr, schrieb Fabio Rizzo Matos : > My awnsers is too slow.... This maybe caused for my way to call the > procedure? It is impossible to tell from the information supplied. Please provide complete information about your platform from the Python progam to the database. 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 mxODBC.Zope.DA for Windows, Mac OS, Linux, Solaris, FreeBSD for free! From fabiorizzo at gmail.com Thu Mar 8 09:08:51 2007 From: fabiorizzo at gmail.com (Fabio Rizzo Matos) Date: Thu Mar 8 13:09:05 2007 Subject: [egenix-users] Calling Stored Procedures In-Reply-To: References: Message-ID: On 3/7/07, eGenix Support wrote: > > Am 07.03.2007, 21:37 Uhr, schrieb Fabio Rizzo Matos >: > > > My awnsers is too slow.... This maybe caused for my way to call the > > procedure? > > It is impossible to tell from the information supplied. Please provide > complete information about your platform from the Python progam to the > database. Hi, Sorry for the missing information. I'm using the latest MXOdbc, from a python 2.4.4 in a Red Hat environment. My Database is a Oracle 10. Is this informations that you need? Thanks 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 mxODBC.Zope.DA for Windows, Mac OS, Linux, Solaris, FreeBSD for free! > -- Fabio Rizzo ThreePointsWeb fabiorizzo@threepointsweb.com ---- -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20070308/f549bb4f/attachment.htm From support at egenix.com Thu Mar 8 14:47:58 2007 From: support at egenix.com (eGenix Support) Date: Thu Mar 8 14:48:14 2007 Subject: [egenix-support] Re: [egenix-users] Calling Stored Procedures In-Reply-To: References: Message-ID: Am 08.03.2007, 13:08 Uhr, schrieb Fabio Rizzo Matos : > Hi, > Sorry for the missing information. I'm using the latest MXOdbc, from a > python 2.4.4 in a Red Hat environment. My Database is a Oracle 10. > Is this informations that you need? What ODBC manager are you using? Are you connecting to the database via a network or on the same machine? Which Oracle ODBC driver are you using? 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 mxODBC.Zope.DA for Windows, Mac OS, Linux, Solaris, FreeBSD for free! From fabiorizzo at gmail.com Fri Mar 9 09:22:46 2007 From: fabiorizzo at gmail.com (Fabio Rizzo Matos) Date: Fri Mar 9 13:23:06 2007 Subject: [egenix-support] Re: [egenix-users] Calling Stored Procedures In-Reply-To: References: Message-ID: On 3/8/07, eGenix Support wrote: > > Am 08.03.2007, 13:08 Uhr, schrieb Fabio Rizzo Matos >: > > > Hi, > > Sorry for the missing information. I'm using the latest MXOdbc, from a > > python 2.4.4 in a Red Hat environment. My Database is a Oracle 10. > > Is this informations that you need? > > What ODBC manager are you using? unixODBC-2.2.11-1.RHEL4.1. Are you connecting to the database via a > network or on the same machine? By Network. The database is in another machine. Which Oracle ODBC driver are you using? Oracle Client 10.2.0.1.0 Something wrong? 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 mxODBC.Zope.DA for Windows, Mac OS, Linux, Solaris, FreeBSD for free! > -- Fabio Rizzo ThreePointsWeb fabiorizzo@threepointsweb.com ---- -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20070309/18a45d5d/attachment.htm From support at egenix.com Fri Mar 9 13:27:09 2007 From: support at egenix.com (eGenix Support) Date: Fri Mar 9 13:27:17 2007 Subject: [egenix-support] Re: [egenix-users] Calling Stored Procedures In-Reply-To: References: Message-ID: Am 09.03.2007, 13:22 Uhr, schrieb Fabio Rizzo Matos : > unixODBC-2.2.11-1.RHEL4.1. > Are you connecting to the database via a > network or on the same machine? > By Network. The database is in another machine. > Which Oracle ODBC driver are you using? > Oracle Client 10.2.0.1.0 You might want to upgrade the Oracle driver- I think there is a more recent one. But that shouldn't make that much off a difference. Have you run any comparative tests using iSQL? How long are the queries taking and how long do they take if you run them directly on the Oracle machine? If there is a difference would it be possible to test the setup on the db as quite often the network is the source of delays. 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 mxODBC.Zope.DA for Windows, Mac OS, Linux, Solaris, FreeBSD for free! From fabiorizzo at gmail.com Fri Mar 9 09:35:18 2007 From: fabiorizzo at gmail.com (Fabio Rizzo Matos) Date: Fri Mar 9 13:35:34 2007 Subject: [egenix-support] Re: [egenix-users] Calling Stored Procedures In-Reply-To: References: Message-ID: On 3/9/07, eGenix Support wrote: > > Am 09.03.2007, 13:22 Uhr, schrieb Fabio Rizzo Matos >: > > > unixODBC-2.2.11-1.RHEL4.1. > > Are you connecting to the database via a > > network or on the same machine? > > By Network. The database is in another machine. > > Which Oracle ODBC driver are you using? > > Oracle Client 10.2.0.1.0 > > You might want to upgrade the Oracle driver- I think there is a more > recent one. But that shouldn't make that much off a difference. Have you > run any comparative tests using iSQL? How long are the queries taking and > how long do they take if you run them directly on the Oracle machine? If > there is a difference would it be possible to test the setup on the db as > quite often the network is the source of delays. I'm not run any test using iSQL, how i run it? The query running in Oracle Machine is fast, but when run by the zope machine, the time is more longer. 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 mxODBC.Zope.DA for Windows, Mac OS, Linux, Solaris, FreeBSD for free! > -- Fabio Rizzo ThreePointsWeb fabiorizzo@threepointsweb.com ---- -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20070309/d953aa7d/attachment.htm From support at egenix.com Fri Mar 9 17:42:24 2007 From: support at egenix.com (eGenix Support) Date: Fri Mar 9 17:42:39 2007 Subject: [egenix-support] Re: [egenix-users] Calling Stored Procedures In-Reply-To: References: Message-ID: Am 09.03.2007, 13:35 Uhr, schrieb Fabio Rizzo Matos : > > I'm not run any test using iSQL, how i run it? http://www.unixodbc.org/utilities.html > The query running in Oracle > Machine is fast, but when run by the zope machine, the time is more > longer. Like I said previously I suspect the network may be the culprit or it might be the ODBC manager. A test with iSQL might help here but a local test (on the same machine as the database would help. 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 mxODBC.Zope.DA for Windows, Mac OS, Linux, Solaris, FreeBSD for free! From david.krosel at maxxian.com Tue Mar 13 08:24:24 2007 From: david.krosel at maxxian.com (David Krosel) Date: Tue Mar 13 13:24:34 2007 Subject: [egenix-users] mxODBC Zope DA and Linux Zope -- Connections not being disconnected References: <013001c72066$e3df1730$0101a8c0@maxdk1> <458857E8.9010305@egenix.com> <00f101c75fff$cb626170$6801a8c0@maxdk1> <010301c76003$3b1eef80$6801a8c0@maxdk1> Message-ID: <108a01c7656a$899b8d00$6801a8c0@maxdk1> Hello, The problem happened again... I didn't change the configuration yet since it was a production system. However, from Zope, the following "Connection Pool" information showed up: -------------------------------------- Pool size: 21 Physical connections: 0 open Total mxODBC connnections: (24,0) -------------------------------------- Does this make since? 24 connections but pool of 21 ? Regards, David VP, Development and Operations Maxxian Integration Inc. 155 Westhampton Drive Thornhill, Ontario Canada L4J 7X2 E-mail: david.krosel@maxxian.com Phone: +1 647 477 2150 Cell: +1 905 598 6548 ----- Original Message ----- From: "Charlie Clark" To: "David Krosel" ; Sent: Tuesday, March 06, 2007 11:32 AM Subject: Re: [egenix-users] mxODBC Zope DA and Linux Zope -- Connections not being disconnected > Am 06.03.2007, 16:22 Uhr, schrieb David Krosel : > >> Hello, >> 21? I thought I would try for a high and safe number When the problem >> occurs again, I will provide a snap-shot, but I couldn't find any errors >> in the Zope log. > > You should also check the unixODBC and MySQL logs. > >> Under the Zope mxODBC configuration screen, there is a note that "Under >> heavy load, closing the connection may not result in the physical >> connections to get freed. This is due to the multi-threaded nature of >> Zope." > >> Can this be related to my problem, even without the load? > > No but if you are in fact not running under heavy load there is probably > not a need for a lot of threads. Please try running Zope and mxODBC with > default values as this may help identify the problem. > > Charlie From howard at eegsoftware.com Tue Mar 13 14:25:05 2007 From: howard at eegsoftware.com (Howard Lightstone) Date: Tue Mar 13 22:25:38 2007 Subject: [egenix-users] debug builds of 2.0.6 for python 2.5 Message-ID: <45F6B441.7958.5C53D1B6@howard.eegsoftware.com> I seem to be having difficulties running mxDateTime debug builds. They build OK but running them leads me to machine faults (referencing 0) during the datetime free logic. It looks to me (naively) that there is a double _py_ForgetReference call once in py_DECREF as the object goes out of scope and again in mxDateTime_Free (the object deallocator function) Since the NON debug versions work, I conclude that the debug version zero out the allocated memory so the second forget call seems to work. It may be my debug builds but I am stumped at this point (on what to do next and how to debug and embedded Python task). And of course, all this worked on Python 2.2........ Thanks From support at egenix.com Tue Mar 13 23:47:56 2007 From: support at egenix.com (eGenix Support: M.-A. Lemburg) Date: Tue Mar 13 23:48:08 2007 Subject: [egenix-users] debug builds of 2.0.6 for python 2.5 In-Reply-To: <45F6B441.7958.5C53D1B6@howard.eegsoftware.com> References: <45F6B441.7958.5C53D1B6@howard.eegsoftware.com> Message-ID: <45F72A1C.1070605@egenix.com> On 2007-03-13 22:25, Howard Lightstone wrote: > I seem to be having difficulties running mxDateTime debug > builds. > > They build OK but running them leads me to machine faults > (referencing 0) during the datetime free logic. > > It looks to me (naively) that there is a double > _py_ForgetReference call > once in py_DECREF as the object goes out of scope > and again in > mxDateTime_Free (the object deallocator function) > > Since the NON debug versions work, I conclude that the > debug version zero out the allocated memory so the second > forget call seems to work. > > It may be my debug builds but I am stumped at this point (on > what to do next and how to debug and embedded Python > task). And of course, all this worked on Python 2.2........ This is a known problem - we never used or supported debug builds in the 2.0 series of egenix-mx-base. The 2.1 series fixed this. You can get the latest snapshot from this message: http://www.egenix.com/mailman-archives/egenix-users/2006-September/114091.html Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2007) >>> 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 mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: From howard at eegsoftware.com Tue Mar 13 17:14:26 2007 From: howard at eegsoftware.com (Howard Lightstone) Date: Wed Mar 14 01:14:44 2007 Subject: [egenix-users] debug builds of 2.0.6 for python 2.5 In-Reply-To: <45F72A1C.1070605@egenix.com> References: <45F6B441.7958.5C53D1B6@howard.eegsoftware.com>, <45F72A1C.1070605@egenix.com> Message-ID: <45F6DBF2.18318.5CEEDD6D@howard.eegsoftware.com> > This is a known problem - we never used or supported debug builds > in the 2.0 series of egenix-mx-base. Urgghhhh.... My python22 debug files were for 0.9 !!! > The 2.1 series fixed this. You can get the latest snapshot > from this message: Thanks. I forgot to mention that the real reason is the necessity to run with VC8 - built executables. I'll do a build tomorrow but thanks for the speedy reply. From mal at egenix.com Wed Mar 14 12:41:38 2007 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Mar 14 12:41:44 2007 Subject: [egenix-users] mxODBC Zope DA and Linux Zope -- Connections not being disconnected In-Reply-To: <108a01c7656a$899b8d00$6801a8c0@maxdk1> References: <013001c72066$e3df1730$0101a8c0@maxdk1> <458857E8.9010305@egenix.com> <00f101c75fff$cb626170$6801a8c0@maxdk1> <010301c76003$3b1eef80$6801a8c0@maxdk1> <108a01c7656a$899b8d00$6801a8c0@maxdk1> Message-ID: <45F7DF72.9000507@egenix.com> On 2007-03-13 13:24, David Krosel wrote: > Hello, > > The problem happened again... I didn't change the configuration yet > since it was a production system. > > However, from Zope, the following "Connection Pool" information showed up: > > -------------------------------------- > Pool size: 21 > Physical connections: 0 open > Total mxODBC connnections: (24,0) > -------------------------------------- > > Does this make since? 24 connections but pool of 21 ? The Zope DA uses the pool size as guideline for managing the number of open connections. It does connection trimming in a better-safe-than-sorry mode which monitors usage of the connections and doesn't force closing of connections still marked as being in use by other threads. It's also possible that you keep mxODBC connections alive by keeping a reference to them elsewhere in the Zope process. This depends on how you use the mxODBC Zope DA connection objects. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 14 2007) >>> 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 mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: From mal at egenix.com Wed Mar 14 13:03:54 2007 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Mar 14 13:03:59 2007 Subject: [egenix-users] debug builds of 2.0.6 for python 2.5 In-Reply-To: <45F6DBF2.18318.5CEEDD6D@howard.eegsoftware.com> References: <45F6B441.7958.5C53D1B6@howard.eegsoftware.com>, <45F72A1C.1070605@egenix.com> <45F6DBF2.18318.5CEEDD6D@howard.eegsoftware.com> Message-ID: <45F7E4AA.7080102@egenix.com> On 2007-03-14 01:14, Howard Lightstone wrote: >> This is a known problem - we never used or supported debug builds >> in the 2.0 series of egenix-mx-base. > Urgghhhh.... My python22 debug files were for 0.9 !!! > > >> The 2.1 series fixed this. You can get the latest snapshot >> from this message: > Thanks. > > I forgot to mention that the real reason is the necessity to run > with VC8 - built executables. I'll do a build tomorrow but > thanks for the speedy reply. Hmm: Python is built with VC.NET (aka VC7) and so are all our extensions in order to prevent any problems related to compiler mismatches. Do you get these problems when using the pre-built extensions in a VC8 compiled Python interpreter ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 14 2007) >>> 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 mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: From gregcorradini at gmail.com Sat Mar 31 09:24:41 2007 From: gregcorradini at gmail.com (Greg Corradini) Date: Sat Mar 31 15:24:45 2007 Subject: [egenix-users] New to mxODBC Message-ID: <429320790703310624y3ce0fffdt884ff521a57e7616@mail.gmail.com> Hello, I'm brand new to mxODBC and fairly new to Python (last 4 months). I tend to learn more from examples at first than documentation. Aside from an mxODBC example at the online Python cookbook and the example on the mxODBC homesite, I've come up short on examples. Does anyone know of sites where I can find more verbose mxODBC examples for Oracle and Microsoft Access? Thanks for your help -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20070331/16333e9a/attachment.htm From charlie at egenix.com Sat Mar 31 16:36:55 2007 From: charlie at egenix.com (Charlie Clark) Date: Sat Mar 31 15:37:11 2007 Subject: [egenix-users] New to mxODBC In-Reply-To: <429320790703310624y3ce0fffdt884ff521a57e7616@mail.gmail.com> References: <429320790703310624y3ce0fffdt884ff521a57e7616@mail.gmail.com> Message-ID: Am 31.03.2007, 15:24 Uhr, schrieb Greg Corradini : > Hello, > I'm brand new to mxODBC and fairly new to Python (last 4 months). I tend > to > learn more from examples at first than documentation. Aside from an > mxODBC > example at the online Python cookbook and the example on the mxODBC > homesite, I've come up short on examples. Does anyone know of sites > where I > can find more verbose mxODBC examples for Oracle and Microsoft Access? Greg, what examples are you looking for that are not covered by the handbook? Depending on your application you may be looking for examples on how the make the most of the Python DB-API using mxODBC. There is a paper from the British Computer Society which provides some examples on using Python objects for your own O/R work. 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 mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX 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 From gregcorradini at gmail.com Sat Mar 31 19:59:12 2007 From: gregcorradini at gmail.com (Greg Corradini) Date: Sun Apr 1 01:59:17 2007 Subject: [egenix-users] Create Table in Access Message-ID: <429320790703311659u31804c04tba749bfdd65c934a@mail.gmail.com> Hello all, I'm brand new to the mxODBC module from egenix (like yesterday). I currently use the module for data laundering. I connect to a Microsoft Access .mdb and perform some SQL queries on tables. Everything is going fine. However, I can't find out how to create a new table. Even other examples that I've found on the web that use the "create table" SQL command aren't working for me. When I run mycursor.execute('create table TEST (nr Integer, val Integer)'), i get a return value of -1. I was hoping somebody with more mxODBC experience could give me a hand with this minor problem. I'm using Python 2.4 w/ the appropriate mxODBC module and running MS XP OS. Thanks Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20070331/2d8ef2b1/attachment.htm