Re: [dba-dev] report: argument Hidden for loadComponentFromURL()
Hi Peter, seems, the property Hidden=false is not supported for report-documents. ... Any hints no, sorry. Any workarounds I could think of (for instance passing a hidden Frame to the loader to plug the to-be-loaded component into) are not implemented for this particular loader. (of course I'll file an issue)? That'd be great, if course. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@dba.openoffice.org For additional commands, e-mail: dev-h...@dba.openoffice.org
Re: [dba-dev] enhance the Query definition code to recognize CALL
Hi Drew, The request is to enhance the query parser components to recognize a command such as CALL somefunction( params ) - allowing escape processing for function parameters -- I don't know what the implications are regarding column names They need to be provided by the DB then, there's not much chance base could obtain them beforehand (as it does when parsing normal SELECT statements). -- Also don't know the cost of supporting this only for the data sources that can utilize it, adding another item/option overhead I suppose --- Question - do the different data sources (SDB, MySQL native, etc) supply code/configuration options to the query component runtime, or is that (the query component code) singular and within it accounts for the different data sources? The parser, and the query designer are pretty generic, they take into account a limited set of meta data provided by the database/driver itself, for instance the list of supported functions, the stuff listed in XDatabaseMetaData, and such. However, there's an awful lot of features which is not covered by meta data, and thus needs either an explicit option, or guesswork, or finally is supported in the parser/designer even if the underlying DB can't handle it. Also, call CUSTOMProcedure( p1...pn ) CUSTOMProcedure returnS a read only result set containing ONE row, columns named p0 to p(n-1) and call CUSTOMFunction( p1...pn ) CUSTOMFunction returns a read only result set with zero or more rows, columns named IN returned result set. Not sure it is feasible to distinguish those. I think recognizing CALL something( parameter_list ) would be sufficient. For the column information, one would have to rely on the DB/driver, anyway, and the number of rows is not of interest to the parser/query designer at all. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@dba.openoffice.org For additional commands, e-mail: dev-h...@dba.openoffice.org
[dba-dev] Recovery process
Hi, seems the recovery process for base has some shortcomings yet. Neither a created report nor the basic code is restored after crashing and starting the recovery (WinXP and m6). A known issue? Regards Peter - To unsubscribe, e-mail: dev-unsubscr...@dba.openoffice.org For additional commands, e-mail: dev-h...@dba.openoffice.org
Re: [dba-dev] Recovery process
Hi Peter, seems the recovery process for base has some shortcomings yet. Neither a created report nor the basic code is restored after crashing and starting the recovery (WinXP and m6). A known issue? http://www.openoffice.org/issues/show_bug.cgi?id=65597 Accidentally, I spent the last ... let me see ... two and a half weeks nearly exclusively to lay some very basic foundations to fix this. (Not in Base. In the framework of the other applications, which needs some heavy re-factoring, so the auto-recovery mechanism can be generalized, so Base can gain control over how emergency-save and crash-recovery are actually done.) Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@dba.openoffice.org For additional commands, e-mail: dev-h...@dba.openoffice.org
Re: [dba-dev] Recovery process
Hi Peter, seems the recovery process for base has some shortcomings yet. Neither a created report nor the basic code is restored after crashing and starting the recovery (WinXP and m6). Hmm ... nor the Basic code? Do you mean that the Basic embedded in your .odb is lost after a crash/recovery? That shouldn't happen at all - is this reproducible? Ciao Frank - To unsubscribe, e-mail: dev-unsubscr...@dba.openoffice.org For additional commands, e-mail: dev-h...@dba.openoffice.org
Re: [dba-dev] report: argument Hidden for loadComponentFromURL()
Frank Schoenheit, Sun Microsystems Germany schrieb: Hi Peter, seems, the property Hidden=false is not supported for report-documents. ... Any hints no, sorry. Any workarounds I could think of (for instance passing a hidden Frame to the loader to plug the to-be-loaded component into) are not implemented for this particular loader. (of course I'll file an issue)? That'd be great, if course. http://qa.openoffice.org/issues/show_bug.cgi?id=107438 Peter - To unsubscribe, e-mail: dev-unsubscr...@dba.openoffice.org For additional commands, e-mail: dev-h...@dba.openoffice.org
Re: [dba-dev] Recovery process
Hi Frank, Am 04.12.2009 10:32, schrieb Frank Schönheit: Hi Peter, seems the recovery process for base has some shortcomings yet. Neither a created report nor the basic code is restored after crashing and starting the recovery (WinXP and m6). Hmm ... nor the Basic code? Do you mean that the Basic embedded in your .odb is lost after a crash/recovery? That shouldn't happen at all - is this reproducible? I meant Basic code inside .odb that hasn't been stored before is lost, yes. Reproducable with http://qa.openoffice.org/issues/show_bug.cgi?id=107438 (ok I know the rules for the issues, if you confirm the behavior, I will open another one). Regards Peter - To unsubscribe, e-mail: dev-unsubscr...@dba.openoffice.org For additional commands, e-mail: dev-h...@dba.openoffice.org
