Hi, Yes, this works. Thank you :)
On Thu, Oct 24, 2013 at 8:19 PM, Pavel Cisar <pci...@ibphoenix.cz> wrote: > ** > > > Hi, > > Dne 24.10.2013 17:21, Harriv napsal(a): > > > > > 2. Data arrives immediately - after I have stopped tracing with tracex. > > > > If I run this configuration with fbtracemgr: > > > > <database MYDATABASENAME> > > enabled true > > log_statement_finish true > > print_plan true > > include_filter %%SELECT%% > > exclude_filter %%RDB$%% > > time_threshold 0 > > max_sql_length 2048 > > </database> > > > > Output is printed immediately. > > Well, I see where the problem is now. There are two methods how to > retrieve output from services via isc_service_query API call: > > a) using isc_info_svc_line request that reads single line per call. > b) using isc_info_svc_to_eof request that fills the buffer provided by > client. It doesn't return until buffer is full or EOF is reached. > > Because services typically provide output with a lot of lines, FDB uses > the second method as it transfers data from server to client > significantly faster. Service.readline() method works on top of this > buffer, so you'll get it's content as individual lines. However, FDB > uses 64K buffer, so you'll not get any output until engine provides 64K > of text for you. > > If you want to get service output by first query method, you have to > query for it yourself. There is fdb.Service._QS() helper method for that. > > Example loop that fetches service output by line: > > while 1: > try: > line = svc._QS(fdb.ibase.isc_info_svc_line) > except fdb.OperationalError: > # It is routine for actions such as RESTORE to raise an > # exception at the end of their output. We ignore any such > # exception and assume that it was expected, which is somewhat > # risky. For example, suppose the network connection is broken > # while the client is receiving the action's output... > break > if not line: # we reached the end of output > break > print line > > > best regards > Pavel Cisar > IBPhoenix > > >
