Re: [sqlite] request for additions to sqlite 3.xx
[13-05-2005 9:31, Chmielewski Andrzej escreveu] comm Wiadomosc ta jest przeznaczona jedynie dla osoby lub podmiotu, ktory jest jej adresatem i moze zawierac poufne i/lub uprzywilejowane informacje. Zakazane jest jakiekolwiek przegladanie, przesylanie, rozpowszechnianie lub inne wykorzystanie tych informacji lub podjecie jakichkolwiek dzialan odnosnie tych informacji przez osoby lub podmioty inne niz zamierzony adresat. Jezeli Panstwo otrzymali przez pomylke te informacje prosimy o poinformowanie o tym nadawcy i usuniecie tej wiadomosci z wszelkich komputerow. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. This is the kind of messages that get into my nerves... Sorry, but I didn't agree on your terms before you sent me the message so (even if it wasn't sent over to a public mailing list) I reserve the right to do whatever I want with it. If you don't agree, then don't send it on the first place. And by the way, a simple link to a public server where the terms are should be more than enough (as it doesn't serve nothing anyway). g
RE: [sqlite] request for additions to sqlite 3.xx
comm Wiadomosc ta jest przeznaczona jedynie dla osoby lub podmiotu, ktory jest jej adresatem i moze zawierac poufne i/lub uprzywilejowane informacje. Zakazane jest jakiekolwiek przegladanie, przesylanie, rozpowszechnianie lub inne wykorzystanie tych informacji lub podjecie jakichkolwiek dzialan odnosnie tych informacji przez osoby lub podmioty inne niz zamierzony adresat. Jezeli Panstwo otrzymali przez pomylke te informacje prosimy o poinformowanie o tym nadawcy i usuniecie tej wiadomosci z wszelkich komputerow. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
Re: [sqlite] request for additions to sqlite 3.xx
> What's the objection to reading your SQL source out of the database and > preparing it at program startup? I have no objection to reading the sql on startup as that is what we are currently doing. I just want all data access code inside of the database instead of my source code. Does anyone else think that SQLite should have stored procedures?? My assumption is that if you are creating views and triggers, why not also create stored procedures aswell. Nearly every other database that has triggers (embedded library or not) has stored procedures aswell. Anyway, as I have pointed out before, I obviously can do without as we are simulating stored procedures by puting them in resource files from one large xml file that can be edited external to the source code. We do not want out data access layer tied too much to SQLite and would prefer to have all access code in the database itself so our data access layer can accomadate (lesser obviously) databases on the market with little change to the code. We can usually work with SQL Server code independant of the application by using stored procedures as our sole access point into he database. SQLite is definitely extremely fast and we have no plans of abandoning due to lack of stored procedures but definitely would be nice to have...
Re: [sqlite] request for additions to sqlite 3.xx
basil thomas wrote: As for storing queries, I'm not sure how useful this feature is given that the database engine itself is part of your program. For simple queries your best bet is a static sqlite3_stmt object, which you prepare once at program initiation and refer back to each time it is needed. Just remember to reset the statement after each query execution. For more complex logic you can couple this trick with functions that choose which query to execute. Clay Dowling Yes I am already creating static statement objects at program init time. That is not the problem. I just do not want the SQL source in my source code as i would like to control the SQL source seperately inside the database I can use all of the c++ functions and do whatever I want. That is not my point either. I am just asking for a standard way to have stored procedures that do exactly the the same simple queries as I am creating now but just implemented as another database object like triggers. The triggers in SQLite are simpled stored procedures fired by SQLite. I just want my own stored procedures fired by my user code. This is a just a simple request that I think others would find usefull. I am already implementing all the other features in my code that simulates a single process/multi-threaded server database. We are using SQLite just as a storage engine as we are fully implementing an xml database on top of SQLite. What's the objection to reading your SQL source out of the database and preparing it at program startup?
