Is it somehow possible to create a stored procedure when using SQLite?
SQLite has had to sacrifice other characteristics that some people find useful, such as high concurrency, fine-grained access control, a rich set of built-in functions, stored procedures, esoteric SQL language features, XML and/or Java extensions, tera- or peta-byte scalability, and so forth
Source : Appropriate Uses For SQLite
Answer: NO
Here's Why ... I think a key reason for having stored procs in a database is that you're executing SP code in the same process as the SQL engine. This makes sense for database engines designed to work as a network connected service but the imperative for SQLite is much less given that it runs as a DLL in your application process rather than in a separate SQL engine process. So it makes more sense to implement all your business logic including what would have been SP code in the host language.
You can however extend SQLite with your own user defined functions in the host language (PHP, Python, Perl, C#, Javascript, Ruby etc). You can then use these custom functions as part of any SQLite select/update/insert/delete. I've done this in C# using DevArt's SQLite to implement password hashing.
Chris Wolf made a prototype implementation of SQLite with stored procedures. You can find the details at his blog post: Adding Stored Procedures to SQLite
Yet, it is possible to fake it using a dedicated table, named for your fake-sp, with an AFTER INSERT trigger. The dedicated table rows contain the parameters for your fake sp, and if it needs to return results you can have a second (poss. temp) table (with name related to the fake-sp) to contain those results. It would require two queries: first to INSERT data into the fake-sp-trigger-table, and the second to SELECT from the fake-sp-results-table, which could be empty, or have a message-field if something went wrong.
No, but you can :
Write long multi-statement scripts
Create temporary one-row tables called e.g. Vars to hold variables
Create a View over a Recursive CTE to program arbitrary functions in pure SQL queries.
So you can do most things you would normally do with stored procs.
For how to program functions in a SQL View see https://www.cafe-encounter.net/p3300/pretending-that-sqlite-has-stored-procedures-and-functions.
Alternatively you can:
Compile short single-page C programs to program arbitrary functions
This is easier and less work than you might think!
A step-by-step guide is at https://www.cafe-encounter.net/p3244/installing-and-using-sqlite-extensions-on-macos-and-maybe-windows-linux-too . This does add some deployment work: you will have to deploy the additional dll/so/dylib files with your application.
I've come across this question myself. I think stored procedures are supported in PHP PDO, but that module is handling it and building normal SQL queries to send to SQLite. So, in PHP, possible to write stored procedures in your code, but no performance gain from using them.
Correct me if I'm wrong, please.
Related
I'm developing an application in asp.Net using VB and an Access database. My client has specified these, and I can't use more robust tools.
My application has to perform a sizable number of logical operations, and SQL is perfect for this. However, because of some of the limitations of Access SQL, I can't really write large SQL statements that do the whole job. Lacking logic testing like IF-ELSE, I'm stuck writing literally dozens of SQL statements. That would be OK, but I'm leery of all that activity against an Access database. Access isn't very stable when you work it that hard.
I've fooled around with funky solutions using things like the SWITCH function, but they look more like spaghetti than actual code. Wouldn't be maintainable at all.
I can upload all of the data into objects in memory and loop back and forth through them using VB logic, but SQL would sure be more efficient.
My question is: is there some object I can create in memory that I can run SQL against? Some recordset-kind of thing? Came up snake-eyes when I searched for this, but I thought I'd ask.
Thanks for any suggestions.
So if I understand your question correctly you currently have to use an Access database as the backend storage but you do not like doing this and would rather pull all data into the application (ASP.Net) and perform your queries against this as if the database was an SQL database in the application. I expect then that you would push the data back.
AFAIK no this cannot be done. While you could put most of the data into objects and do the manipulation there you will not have the relationships etc. but you could try using LINQ or entity framework.
This link below explains that you can do LINQ with MSAccess and that may give you the query power you want.
Query Microsoft Access MDB Database using LINQ and C#
I'd like to know the best architecture.
We have a web application running different domains. Each domain has its own MySQL database but the db structure is the same for all of them.
We have a web application for the visible part of the application.
We have a dataLogic project
We have a dataEntities project
We have a dataAccess that contains only the methods to connect to the data base.
Before we called stored procedures on a database. But we had to change it because the performance was bad. Also, the problem was that every change we made we had in a stored procedure we had to copy to every database.
We are thinking in using a WebService to retrieve the data. Every domain can call the web service with a connection string and connect its database to retrieve data. This way when we change a SQL query we only have to compile the webService and change it, we don't have to change versions on multiples domains.
Also, what do you think about the SQL queries? Since we don't want to keep using stored procedures, what is the best way to do it? Directly from code?
Thanks
T
If you have multiple Database servers you will have to make Structural changes from one DB to another one way or another. There are many tools to change Database structures. These tools will look for differences between Schema, and will either generate the SQL code for you, or do the changes by itself (it depends a lot in the tool, there are powerful ones and not so powerful ones). Please do take a look at Toad for MySql. Now, for the Data changes, you may want to replicate the data from one Database to another. This is done through Replication.
We are thinking in using a WebService to retrieve the data. Every
domain can call the web service with a connection string and connect
its database to retrieve data.
This sounds like a good idea and since you already have "dataAccess" and "dataLogic" projects, it should not be too hard to make the services.
Also, what do you think about the SQL queries? Since we don't want to
keep using stored procedures, what is the best way to do it? Directly
from code?
I don't think it is a good practice to have the SQL queries directly into your code, but it depends in a lot of things, so I would suggest Stored Procedure vs Hard-Coding the queries, or LinQ (Entity Framework 4.1).
Good luck with your project and I will take a look at this thread frequently to see what you end up doing.
Have fun!
Hanlet
Which one is preferable for Enterprise CMS development:
LINQ or SP?
Generally what I do is LINQ to Views and LINQ to Stored Procedures. It's not a question of what is preferred because LINQ solves how to manage the data once it's queried where Stored Procedures are run on the SQL side to allow for query manipulation (or for me, mostly saving) of data which takes away from having the code to do it which is slower.
I would say you would want to use both if necessary. Are you saving to Entities that require multiple tables saves as one Entity? If so, use Stored Procedures with LINQ. If you're using 1 to 1 Entity relations to your tables then just use LINQ.
Stored Procedures can be used with Linq2Sql (and Entity Framework), so it isn't a choice of one or another.
I would cache the results from the database for a CMS as you likely to get the same data requested over and over again (cache the dataset, or use page caching, or cache the objects if using LINQ).
Then it doesn't matter if you use LINQ or an SP, but I would just use LINQ.
For simple CRUD table(no joins !!!) operations LINQ to SQL is fine, however for anything more complex (needing joins) I always use stored procedures (you can use Linq to stored procedures if you wish)
There are numerous debates around this on this site and others. For me, you can normally split the pro Linq camp into guys who have recently come into programming and have not had the history of having to use Stored procedures, ie not been heavily involved in the database side of previous projects.
Form my experience of working on several projects using pure LINQ, stored procedures and a mixture of both these are the two reasons I would stick to Linq for basic CRUD and stored procedures for anything more complex or relying on performance.
1 - Deploymenty/Security - Anyone that has worked in the real world a knows full well that having the database logic separated into stored procedures and not incorporated into the source code and released DLL is a massive advantage. You can add a proper security/access layer around each query using roles and SQL server security, imperative for any serious enterprise level company, and you can also make changes to the SQL of any stored procedure without having to do a new release of the main application (dll). I dont care how good you claim to be we have all had to fix live issues and performance bottlenecks using stored procedures and having to do this with a new application release would have been a nightmare.
2 - Performance/Code Smells - I have seen so many applications littered with huge amount of of badly written and inefficient Linq. Developers get lazy with Linq, little hidden lazy Linq to SQL queries which cause you a nightmare trying to debug performance issues on an enterprise level system - the motto 'get it done as quick as possible' seems prevalent. I have seen more Spaghetti code since the advent of Linq than I had seen with any previous class library/pattern Microsoft have released since COM.
We can precompile our (ASP.NET) websites and can publish only the IL code, so that the source code is not available to the customer.
But how do we do it for stored procedures written in SQL Server. I mean, when we give the customer the DB, he could see all my stored procedures and can modify the same... How could I protect it.
Thanks
Raja
An old problem. Here are a few answers I've picked up here and there:
Encrypt the stored procedures. As has
already been pointed out twice, this
doesn't really work, as 5 minutes of
Googling will find several hacks.
Write the stored procedures as CLR
procedures. Harder to hack than
"regular" stored procedures, probably
a lot more effort to produce and
support.
Submit all queries dynamically from
your compiled IL code. I understand
it can be done reasonably secure from
SQL injection attack, but make darn
sure before you release. (Maybe use Linq to do this?)
Convert all database object names
(tables, columns, procedures) to
guids or random gibberish. They could
read it, but that wouldn't help much.
I am not totally conversant on encryption within SQL 2005 and up. I really don't think you can use it on code-based objects (procedures, functions, etc.), but maybe you can?
But by and large, once you give a copy of your database to someone with SysAdmin rights, they can do pretty much anything they want with it.
use WITH ENCRYPTION
example
CREATE PROCEDURE prTest
WITH ENCRYPTION
AS
SELECT GETDATE()
Keep in mind that it can be cracked and also make sure you have the unencrypted source code backed up
CREATE PROCEDURE ... WITH ENCRYPTION
However note that this encryption is really more like obfuscation, and there are several ways to bypass it if your vendor is determined, including the DAC connection, some 3rd party products (including RedGate SQL Prompt), and code samples you can readily find online.
I'm deploying a web site and I need to run large TSQL scripts contained in a single file in a production server where I don't have full access to SQL Server console and I can't connect remotely. The scripts is a mixed of table, stored procedures and views creations. All I can do is to run 1 group of TSQL sentences, like the ones for a stored procedure.
I have two options: to parse the file manually looking for GO's sentences and run each block of sentences before that GO, or to do the same task but with a tool. Using a tool I will be very fast doing the task, but I don't know any tool such that.
Do you know any tool that I can use?
I think it must be something like a control, with an editor where I will paste or load the scripts to run, and it will be able to parse and run them in sequence, like the Microsoft SQL Server Management usually does.
You could check out some articles on CodeProject on the topic and maybe use one of those tools / component for your needs?
Universal Database Admin for ASP.NET and SQL Server (Reloaded)
ASP.NET Database Admin Control
Web SQL Utility
Most of those come with full source and could also serve you as a starting point for a custom version of your own.
Marc
you got many options
usually i create stored procedure in sql management studio then save it as string, then use linq2sql to execute the stored procedure, works very well.
use sql server smo object where you can really do mostly many things like creating DBs, tables, it is really cool, i create 1 page on my site and use it to update DB with it.
here is a good link for that
http://www.sqldbatips.com/showarticle.asp?ID=34
you can use Redgate SQL data compare, and Compare. they rock really to synchronize DBs, it have saved me a lot of time and it is super easy, highly recommended really.
hope this helps.
If those don't work, it's pretty easy to write such a tool yourself. Just use Regex.Split to split the text on the GO lines, then loop, calling ExecuteNonQuery for each section.