I'll do that. I was troubled enough by that bug report and this new testing info to be so motivated. :-)
If I think about it, the copy method has "filename" as an argument, and a dump method for the tcl driver would need that too. All other methods I believe do not need to specify the filesystem particulars (i.e. a filename path). Is that (partly?) why the copy is not tested and why there is no db1 dump filename method? -T [EMAIL PROTECTED] wrote: Travis Daygale wrote: > That is useful to know (i.e. non-testing of the shell). Thanks. > > Does "the core" include the tcl driver (what I use)? (It must- the driver is > in there and the testing is done with tcl, all of this being partly why I > chose tcl for my app- but I want to make sure I'm not somehow > misunderstanding...) Everything except the COPY command is tested. > > Then: > > How might one do the equivalent of a .dump from a trivial tcl script (and > therefore avoid the shell)? Sort of a reverse "copy" method... and not the > same as logging (trace). Is there a way to dump from tcl? Am I being stupid > here- I haven't seen it... > > Based on the testing info, if one could do this, presumably one would have a > (more reliable) dump/backup in a simple script. (And if it happens that > one's sqlite code is tcl using the tcl driver, as mine is, so much the better > in all kinds of ways including crossplatform considerations.) > It would probably not require more than a few lines of TCL code to implement a "dump" command as a TCL proc. Why don't you work something up and post it on either the TCLers wiki or on the SQLite wiki or both? -- D. Richard Hipp ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] ----------------------------------------------------------------------------- --------------------------------- Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta.
