Hello Ariel, > Basically, the value for the DataAccessDescriptor property "Command" was > wrong in a dBase source (then I did the same intentionally with a CSV > source): I had to pass the file name without extension in both cases as > command, but I passed a wrong name.
That's what I also know so far: The crash happens when you pass a wrong (non-existing) table name. > The problem is that the constructor did not throw any exception, I could > get an XCopyTableWizard reference and use all the methods > ... > but when invoking XExecutablaDialog::execute(), OOo crashed. I still think the crash is completely unrelated to the wizard, and your stack supports this. When I know what causes it, I will probably also know how to reproduce it outside the wizard :) > Shouldn't all arguments be tested first by the constructor and throw an > exception there, instead of making OOo crash? :-( Not sure. Finally, between creating the wizard, and executing it, somebody could drop the table which you just passed - you always need to expect an error upon execute. (An exception, that is, no crash.) > I attach the log, be aware that as I always debug in NetBeans, maybe > there is Java-specific info, nothing to do with the actual cause of OOo > crash (at least libdbtools680li.so is in the log) The stack is what I see here, too, so at least I know we're talking about the same problem. Thanks & Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
