Fam. Sera schrieb: > Is there a reason why the command line interpreter supports more functions > while the dll does not? > > I would like to create an application using SQLite with and in memory > database. I have some big text files (csv), which can be imported nicely by > the command line interpreter using the .import command. However when later > on, I'd like to manipulate data, using the DLL - or it's compiled version - > in my application I cannot access the in memory database created earlier > using the command line interpreter. Obviously the DLL open command creates a > new in-memory database instance. On the other hand, the DLL itself does not > offer the great .import or .output functionalities.. > > I wonder why the DLL version does not support those dot commands supported by > the comand line version? > > Best regards, > > Zsolt Sera > Vienna > > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > It's easy enoug to transform sqlite command line tool into a GUI-Window.
For short there are three different approaches : A) You use Borland's C++ 5.0 which has a window control that emulates a command line window. I did this with other command line applications and it works. B) You can use the code for sqlite and do the following : Overwrite all standard functions for stdio with your own versions and translate them into calls for GUI routines. This sounds terrible but in reallity is is very easy. What you really need is an edit control and a minimal amount of own code for redirection. When you use this method you'll end up with having a emulated command window in your application which allows always administration from a GUI application with the power of the sqlite command line and it's dot commands. I think that many programmers would profit from a little changed sqlite command line tool in which each of the included standard function names would be Pointers to functions or to an "struct-object" with a function pointer table. That would make porting and such uses as a GUI command line much easier. I did it this way and have to search->rename each time a changed version appears. C) The third way to keep the functionality of sqlite command line and integrate it in your application would be to seperate the integrated parser of this tiny useful tool and wrap all user interface routines with GUI or script-functions. This is also not very hard to achive because sqlite command line tool is prepared for this tasks and has a string parser so it doesn't really care from which source the string really comes. If you really need such a administrative windows or a function interface in your gui application sqlite command line is very good and easily to transform into a gui application. Method B is the one i personaly prefered because when you once have a window which is able to simulate a console you can exchange your personal administrative dll with the regular code after search-rename. Some would advice to redefine standard function names with makros but that is dangerous. It's better to rename them like printf ==> myprintf and declare a function pointer for myprintf. With a Makro selection you can than declare this pointers as standard function pointers or substitute them with your own implementations. Hope i could help you _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
