good morning *** holycow has quit IRC *** dimas has joined #gnuenterprise *** reinhard has joined #gnuenterprise *** kilo_ has joined #gnuenterprise good morning *** btami has joined #gnuenterprise good morning *** johannesV has joined #gnuenterprise *** sjc has joined #gnuenterprise good morning @seen ajmitch reinhard: ajmitch was last seen here 3 weeks, 3 days, 19 hours, 38 minutes, and 39 seconds ago saying: * ajmitch checked the deb from the ubuntu mirrors, it has the right permissions for the directory @seen ajmitch_ reinhard: ajmitch_ was last seen here 1 week, 3 days, 5 hours, 53 minutes, and 13 seconds ago saying: hi good morning johannesV: using empty username in login dialog (wx or gtk2) i get this error File "/home/tamas/svn/gnue/.cvsdevelbase/gnue/common/datasources/drivers/DBSIG2/Connection.py", line 268, in makecursor cursor.execute (s) File "/usr/lib/python2.3/site-packages/kinterbasdb/__init__.py", line 1582, in execute self.description = _k.execute(self._C_cursor, sql, params) ProgrammingError: (-551, 'isc_dsql_prepare: no permission for read/select access to TABLE UGYFEL. ') hmm i've tried with my firebird here ... but i get a login-error if i try without a user (-923, 'isc_attach_database: connection rejected by remote interface.') have you added an 'empty' user to your security database (using gsec) ? should we? no i don't know ... but as i've said: i even cannot connect to the db using 'no' username so i was just wondering how you can produce this situation johannesV: i'v never used gsec manually there is only sysdba in my security.fdb USERS tabla hm, do you connect from the same (local) machine ? yes ok, i cannot simulate that situation here. and the login-dialog passes successfully for you ? yes that's really strange it gives back empty strings for _username and _password since the procedure is: ask for missing login-fields, and pass that dict to connection.connect () method; if there's an exception raised by this, create another login-dialog and my call to 'connection.connect ()' properly raises an excpetion (as given above) so the question is why is there no exception raise by your db erm s/raise/raised/ btami, it has to give back empty strings for _username and _password, since you have entered that, didn't you ? i use Firebird 1.5.2 yep LI-V1.5.1.4500 Firebird 1.5 tamas:~$ python Python 2.3.4 (#1, Jan 14 2005, 20:14:16) [GCC 3.3.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import kinterbasdb >>> con=kinterbasdb.connection(dsn='/home/tamas/data/ugyfel.gdb',username='',pas sword='') Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'connection' >>> con=kinterbasdb.connect(dsn='/home/tamas/data/ugyfel.gdb',username='',passwo rd='') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/site-packages/kinterbasdb/__init__.py", line 476, in connect return Connection(*args, **keywords_args) File "/usr/lib/python2.3/site-packages/kinterbasdb/__init__.py", line 613, in __init__ (dsn, dpb, dialect) = self._build_connect_structures(**source_dict) TypeError: _build_connect_structures() got an unexpected keyword argument 'usern ame' >>> con=kinterbasdb.connect(dsn='/home/tamas/data/ugyfel.gdb',user='',password=' ') >>> con >>> cur = con.cursor() >>> cur >>> cur.execute('select * from ugyfel') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/site-packages/kinterbasdb/__init__.py", line 1582, in execute self.description = _k.execute(self._C_cursor, sql, params) kinterbasdb.ProgrammingError: (-551, 'isc_dsql_prepare: no permission for read/s elect access to COLUMN CEG. ') >>> sorry ok, will try that here ... * btami goes to try on XP >>> con = kinterbasdb.connect (dsn='langley:/home/dbms/firebird.gnue.fdb', user='', password = ' ') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/site-packages/kinterbasdb/__init__.py", line 476, in connect return Connection(*args, **keywords_args) File "/usr/lib/python2.3/site-packages/kinterbasdb/__init__.py", line 614, in __init__ *** btami has quit IRC self._C_con = _k.attach_db(dsn, dpb, dialect) kinterbasdb.OperationalError: (-923, 'isc_attach_database: connection rejected by remote interface. ') *** btami has joined #gnuenterprise XP is ok, hmm btami, what do you mean with "ok" ? do you get the exception too ? i can't get connection with empty user ok so you see it's not a pb with the login-dialog :) :) anyhow, it's not a big problem, just strange kilo uses a binary distributed original Firebird and can reproduce it (i'm using the packaged by myself) ok, let's go on, and forget this (not gnue) problem :) *** docelic has joined #gnuenterprise *** johannesV has quit IRC *** johannesV has joined #gnuenterprise *** dcmwai has quit IRC *** d99rynik has joined #gnuenterprise *** rynik has quit IRC *** yure has joined #gnuenterprise *** sjc has quit IRC *** btami has quit IRC *** dimas has quit IRC *** dimas has joined #gnuenterprise *** d99rynik has quit IRC *** rynik has joined #gnuenterprise *** kilo_ has quit IRC *** d99rynik has joined #gnuenterprise *** johannesV_ has joined #gnuenterprise *** rynik has quit IRC *** dcmwai has joined #gnuenterprise *** titopbs has joined #gnuenterprise *** johannesV has quit IRC *** johannesV_ has quit IRC *** titopbs_ has joined #gnuenterprise *** johannesV has joined #gnuenterprise *** johannesV has joined #gnuenterprise *** titopbs has quit IRC *** SachaS has left #gnuenterprise *** jamest has joined #gnuenterprise *** titopbs_ has quit IRC johannesV: do you have a minute? *** dcmwai has quit IRC sorry, have to leave *** johannesV has quit IRC mnemoc: maybe I can help you? sure i can't find the missing close() on my .py :( can you give it a look? please you are far more experienced than i what exactly makes you think that your program leaks? after some loops i got gnue-appserver consuming 480m you might be aware that if you create a resultSet with 1000 records and you iterate th errm sorry skip that and i got some postgres idle transactions also after some loops of what? after running the whole program several times? that .py is executed 72 times once per backup ok is every dbf about same size yes ok do you want one .tar.bz2? makefile whould do the rest does appserver's memory usage change with every loop linearly? yes i 'improved' the script by commiting inside the loops and not outside... that was an important performace improvement but i still have 'idle transations' and high memory usage my first try took 9 hours on one call with commit() outside the for-loop now it takes 50-55 with commit() inside the for-loop mnemoc: that was with release appserver, right? exactly this performance problem was solved by johannesV lately my svn has about one week old does that mean my script is correct and i can run it again without problems? (after updating my working copy of gnue-trunk) mnemoc: no, I meant the 9 hours thing that was before you switchted appserver to svn, right? as it should not happen with svn (neither current nor 1 week old svn) uhm... yes i just move appserver to svn after you changed auth names user to username or something like that i was using svn only for my language.app due to dbf broken on 0.5.14 i guess i got it.... do i need to close() appserver.find() output? so you could try (just really as a try) to move the commit outside the loop again and then see what changes ok i do three: foo = appserver.find if foo: foo=foo[0] leaving the findset on limbo i guess hmmm I don't think that's a problem I do this several times in some projects actually it should close all cursors at latest when you close the session oh script with commit outside the loop started uhm no... abort i have orphan gnue-appserver sessions (processes) killall python2.4 and no "postgres idle transactions" left bbl, must look after kids *** yure has quit IRC *** dimas has quit IRC *** yure has joined #gnuenterprise *** SachaS has joined #gnuenterprise *** sjc has joined #gnuenterprise *** titopbs has joined #gnuenterprise *** kilo_ has joined #gnuenterprise *** d99rynik has quit IRC *** rynik has joined #gnuenterprise *** sjc has quit IRC reinhard: you were right, performance is solved. 56m with commit inside the loop, and 58m with commit outside the loop reinhard: but i still have the idle postgres transaction reinhard: and session.close() _is_ being called at the end mnemoc: *the* idle postgres transaction does mean *one* idle postgres transaction? that would be ok; appserver has *one* connection to the db always open cu tomorrow night all *** reinhard has quit IRC *** jamest has left #gnuenterprise *** yure has quit IRC *** kilo_ has quit IRC *** nickr has quit IRC *** nickr has joined #gnuenterprise *** nickr has quit IRC *** nickr has joined #gnuenterprise *** holycow has joined #gnuenterprise *** nickr has quit IRC *** nickr has joined #gnuenterprise *** titopbs has quit IRC *** mnemoc_ has joined #gnuenterprise *** menomc has joined #gnuenterprise *** mnemoc has quit IRC *** docelic has quit IRC *** holycow has quit IRC *** dimas has joined #gnuenterprise