What is a dynamic SQL query, and when would I want to use one? I'm using SQL Server 2005.
Here's a few articles:
Introduction to Dynamic SQL
Dynamic SQL Beginner's Guide
From Introduction to Dynamic SQL:
Dynamic SQL is a term used to mean SQL code that is generated programatically (in part or fully) by your program before it is executed. As a result it is a very flexible and powerful tool. You can use dynamic SQL to accomplish tasks such as adding where clauses to a search based on what fields are filled out on a form or to create tables with varying names.
Dynamic SQL is SQL generated by the calling program. This can be through an ORM tool, or ad-hoc by concatenating strings. Non-dynamic SQL would be something like a stored procedure, where the SQL to be executed is predefined. Not all DBA's will let you run dynamic SQL against their database due to security concerns.
A dynamic SQL query is one that is built as the program is running as opposed to a query that is already (hard-) coded at compile time.
The program in question might be running either on the client or application server (debatable if you'd still call it 'dynamic') or within the database server.
Related
I have an application that is supposed to support two types of databases SQL SERVER and ORACLE. So we've been working forever on SQL Server and now we are making this support.
My idea was to create a tool to generate the scripts of creating the database using CMO then convert those scripts to PL/SQL Oracle scripts and run them on Oracle.
My questions are:
Is this syntax conversion possible in code?
I need a guideline to make this kind of syntax conversion.
Do you have a better suggestion to maintain two types of databases (i mean when making a change of one of them, we dont have to make it to the other. we need a tool to make that change.)?
If you write using standard sql it should be mostly portable. Eg use fetch instead of top, SET #a=.. instead of Select #a=.. Use Merge for updates instead of join updates, CURRENT_TIMESTAMP instead of getdate() etc.
I work in a project where the UI has direct access to the database through SQL code. The company has a framework where we create UI pages in xml and after that it is parsed and creates FLEX pages. If we want some data from the DB (Oracle) we add a sql query in the xml (instead of databinding with a datacontext object like we could do with WPF). If we want to add some logic, there is no code behind, we call store procedures. After we have the data we need the parser does the job.
The new requirements are to use the framework and create a new product that will be compatible with SQL Server and the thoughts are to start transforming the (Oracle)SQL queries to ANSI SQL.
Can somebody tell me the benefits and mainly the problems that we are going to face doing that?
Do you think there is a better way?
Note: The framework is really big and there are a lot of products built on that so managers are not keen to just throw it away(I tried but.. :))
Each dialect of SQL is different. You could use ANSI SQL but a) not all of ANSI SQL is implemented by most DBMS and b) most DBMS's have implementation-specific optimisations which will perform better for some cases.
So I'd say, don't go for ANSI SQL. It won't always work and sometimes it will work slower than taking advantage of a vendor's non-standard implementations.
Specifically, Oracle requires a StoredProcedure to return a REF_CURSOR from a stored procedure to fill a DataSet. SQL Server doesnt; the SP returns what the sp SELECTed. You're going to have to change your SP's to get rid of the returned REF_CURSOR.
Date handling is quite different: Oracle needs a to_date to turn a string into a date in where clauses etc; SQL Server just takes the string and converts it for you. And so on and so on. (I'm not at all sure what the ANSI Standard is, or even if it covers this!) To avoid changing your SQL you could add create SQL Server function called to_date, but this is now going to slow up your SQL.
If you have much PL/SQL in stored procedures, you have a big job converting it to T-SQL. They are quite different.
Good luck!
Can I avoid all SQL-injection attacks by using parameters?
And don't worry about any thing in SQL injection in this case?
Or are there some types of these attacks which require more care on the part of the programmer?
No, you can't avoid all SQL injection attacks by using parameters. Dynamic SQL is the real issue, and this can occur in stored procedures as well as in your application code.
E.g., this is prone to a SQL injection attack: your parameterized query passes a username to a stored procedure, and within the stored procedure the parameter is concatenated to a SQL command and then executed.
For an example of many kinds of SQL injection attacks, see this SQL Injection Cheat Sheet. You will see that simply escaping single quotes is just scratching the surface, and that there are many ways around that.
Yes and no. Yes, if all of your SQL statements are indeed static and use only parameters, then you're 100% protected from SQL injection attacks.
The problem comes when the parameters themselves are used to construct dynamic SQL statements. An example would be a stored procedure that generates a SQL statement dynamically for querying a multitude of different options, where a single monolithic statement would be impractical. While there are better solutions to this problem, this is a common one.
Yes you can avoid all SQL-injection attacks by using parameters, as long as you use parameters exclusively all the way down the call stack. For example:
Your app code calls a stored procedure or dynamic SQL in the database. That must use parameters to pass all values.
The stored procedure or dynamic SQL internally constructs a call to another stored procedure or dynamic SQL statement. That must also use parameters to pass all values.
Repeat ad-infinitum until you run out of code.
If you are programming in SQL Server, you can use sp_executesql to execute dynamic SQL, and it will let you define and pass parameterised values to the statement being executed.
If you are going to build a dynamic sql query with those parameters (passed to a stored procedure, for example) then there's a chance of sql injection if precautions are not taken.
You can always minimize the risk of SQL injection by using prepared statements, provided your database engine supports them.
Anyway, prepared statements is probably the most secure way of blocking SQL injections.
The problem is building the SQL statement dynamically.
For example, you might want to order the result based on the column the user selected. In most databases, you can't use parameters here ("ORDER BY ?" doesn't work). So you have to "ORDER BY " + column. Now, if "column" is a String, then the user of your web-application could inject code there (which is not easy, but possible).
Do linq generated queries get cached effectively by SQL Server 2008?
or is it better to use stored procedures with linq or what about a view and then using compiled linq queries... opinions?
cheers
emphasis here is on "effectively", and or is it better....
ie. views are cached well by sql server, and then using linq on the view....
On top of the answers already given according to Damien Guard there's a glitch in the LINQ to SQL and EF LINQ providers that fails to set the variable lengths consistently for queries involving string parameters.
http://damieng.com/blog/2009/12/13/sql-server-query-plan-cache
Apparently it's fixed in .NET 4.0.
In the past I've written stored proc's in place of LINQ queries, mainly for complex reporting-like queries rather than simple CRUD but only following profiling of my application.
L2S simply passes queries on to SQL Server 2008. So they will get cached, or not cached, like any other query submitted by any other process. The fact that a Linq query is compiled has no impact on how SQL Server processes the query.
Queries that LINQ generates are normal SQL queries like your own hand-crafted SQL queries, and they follow the same rules: if the query text is identical (down to the last comma and whitespace) than a query text before, chances are its query execution plan might have been cached and thus able to be reused.
The point is: the query text has to be absolutely identical - if even a single whitespace is different, SQL Server considers it a new query and thus will go through the full process of parsing, analysing, finding a query plan and executing it.
But basically, yes - queries sent off by LINQ will be cached and reused - if they meet those criteria!
Does anyone know how to generate SQL scripts from a query?
For example,
Script some tables.
Do custom action 1.
Script the views.
Do custom action 2.
Etc.
It sounds like you want to write a cursor to execute custom SQL. This is common and easy to do. What you need to do is specify a few things to help us more completely answer your question:
What type of SQL server are you using? (MSSQL, Oracle, MySQL)
What language are you writing in? (Java, C++, PL/SQL, TSQL)
You can either write code (Java / C++) to generate SQL from a query, or possibly use a cursor to iterate over recordsets (PL/SQL / TSQL). You can use the results to give you information that can then be executed as SQL via an exec (of some kind depending on the language).
... but please investigate SQL injection before implementing dynamic SQL. Look into Parameterized Queries...
With Microsoft Sql Server, the best way to script database objects is to use SMO. Sql Management Objects is a c# api, but you could always execute t-sql scripts from c# using a SqlClient.
You could want something like
select 'UPDATE '+table_name+ ' SET description=''(new!) ''+description WHERE description_date>''2008-11-01'''
from information_schema.tables where table_name like '%Description'
(this query generates queries which prepend value of description column with '(new!) ' for each recent row in each table which name ends with 'Description' in a fictional database).
The system view INFORMATION_SCHEMA.TABLES contains data about all database tables, there are also INFORMATION_SCHEMA.VIEWS, INFORMATIONS_CHEMA.COLUMNS and other system views in INFORMATION_SCHEMA table schema.
Hope this will help.