> 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...
