Hi Ray, lots of questions ... Most of the times you will read me saying "please visit IssueZilla". That's simply 'cause you raised some good points, which are worth being filed so we can eventually address them. Filing them in IZ is the only way (though no guarantee :-\) they won't be forgotten.
> OO DSE in OO Calc > insertion into OO Base HSQLDB embedded I assume you do this insertion via copy'n'paste or drag'n'drop ... > * OO Basic in batch continuation > ... > desired solution: > - either OO BeanShell module capable of multiple routines Can't say anything about this. > - or OO Basic capable of catching exception On Error Goto Label Label: ' do something with Error$ Not sure about Error$, but something like this. Ideally, you do this in a small Sub copying a single record., the "On Error Goto" will apply to this Sub only, then. > * DSE corrupted unicode content > > All Unicode content is corrupted during > insertion in batch mode (10k - 20k rows) > from DSE in 2.0.4 OO Calc into OO Base. > > Unicode display is OK for OO Calc content. > Unicode display is OK for OO Base content > displayed through DSE inside OO Calc. > Unicode insertion is OK for OO Base HSQLDB CUI > (Tools - SQL, both embedded and stand alone). > ... > Is there a button to enable the Unicode content > insertion into OO Base through DSE in OO Calc? It should work out of the box, of course. If it doesn't, please submit an issue, with a small sample spreadsheet (and preferrably with a small sample database), and a precise description of what you're doing (The above leaves some question open, in particular how exactly you do the insertion). Thanks. > * DSE for more than 10k - 20k source rows > > What is the extra warning about "... value too large ..." > during the insertion of more than 10k - 20k rows through > DSE in OO Calc into OO Base? > > Is it about the source data content? > Is it about something else? > Does it change or corrupt the data input, and which rows? Can't say anything here without knowing more. You don't tell which way of insertion you use (scripted or by UI). Also, it might depend on either the record number (which I somehow doubt) or some concrete record value. Please elaborate what you're doing. > * DSE table name in data insertion > > Users should be able to drag the source range in OO Calc > unto a table in DSE, not just the "Tables" section title. > The selected table in DSE should be the default table name > for data insertion through DSE, subject to user revision > in case of mis-drop during the drag-and-drop. Agreed. Do you mind submitting an RFE in IssueZilla? > * DSE for Identity columns > > Null in source range will fail insertion into Identity columns > through DSE in OO Calc. Arbitrary numbers have to be assigned > in OO Calc source ranges for insertion into Identity columns. > This is impractical for data appending operation as the current > Identity() state is required to not cause insertion failure > (an undesireable scenario of database repair). Agreed. You know my next sentence? :) Please submit an RFE in IssueZilla. > * DSE batch indicator > > Currently DSE in OO Calc does not clear the dialog windows > before the execution of data insertion into OO Base. > The display is mangled and frozen for some time during the > insertion of large amount of data (10k - 20k rows, and more). That's basically a missing repaint, the dialog is long-closed ... I'd give this P4, but'd nonetheless say it justifies an issue. > * DSE batch error processing > > The current dialog for data insertion through DSE in OO Calc > into OO Base is designed only for interactive operation. > In batch data insertion (> 20k rows), there is no way > to record data rows (can be many) that fail the SQL execution, > possibly due to violation of referential integrity, etc., as > stipulated by database design. > > Need an additional dialog for user specified location of cell range > into which all offending source data rows will be recorded > for post mortem diagnosis. Interesting idea. Hard to realize out of the box, since this dialog is used in much more cases than when copying from Calc, so we would need to think what to do in other cases (people might want to log to files, database tables, whatever). Perhaps a generic (and much easier) "log to (CSV-)file" is sufficient, this could easily be imported into Calc then. Again, what about visiting IssueZilla? > * DSE interactive error processing > > Interactive operation is useful for small scale testing. > The current error message is of no value: > Insert Into user_table Values ( ?, ?, ?, ... ) > > It is probably directly dumped from JDBC PreparedStatement code. > All "?" should be replaced with actual user data content, > since DSE already holds the info. for JDBC PreparedStatement. It's somewhat more difficult than this, but in general I agree that the diagnostics can probably be improved here. Please file an example in IssueZilla. > * DSE ad-hoc connection to data source > > This issue has been previously discussed in this forum. > Users should be able to connect to data sources ad-hoc > inside DSE, without registration of data sources. > Users should not have to switch out of DSE, > move to a separate GUI (currently Tools - Options - Base etc.), > register the selected data sources, > switch back to DSE, > and then continue data analysis. Since quite a while, we have at least a "Registered databases ..." entry in the DSE's context menu, which directly leads you to the registration dialog. That somewhat eases the pain. Registering *arbitrary* data sources without an .odb file would be much more difficult. This touches the question discussed elsewhere in this list recently: "Data Sources" vs. "Database Documents". Currently, OOo as a whole is designed for the latter. > This need of ad-hoc connection emerges mostly for > analysis and decision making based on multiple data sources. > Such operating styles occur often in larger business entities, > with resources to collect and process multiple types of info., > in contrast to smaller business operations. I definately see this need ... You might, again, want to visit IssueZilla. I doubt that there's an easy solution (mixing both concepts transparently is more complex than presenting only *one* - data sources or database documents - to the user, as we did/do in 1.x resp. 2.x), but it's worth being considered and thought about, IMO. Thanks & Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
