I have been researching the names of the SQL versions used by different DBMSs.
So far I have:
Microsoft SQL -> Transact SQL
PostgrSQL -> PL/pgSQL
MySQL -> standard SQL (ANSI)
Oracle -> PL/SQL
Firebird -> ?
I haven't found anything about this. I read somewhere that it's PSQL, but I'm not sure if that is true, since the search results for it return many pages about postgres...
Firebird simply has SQL, which is very close to standard SQL (probably closer than MySQL), it then discerns a number of different variants:
SQL, the basic variant (although some of the old InterBase documentation seems to use this to refer to ESQL as well)
ESQL (or Embedded SQL) which allows use of SQL directly in code (using a preprocessor), not used much these days
DSQL (or Dynamic SQL), this is what you usually use when executing queries against Firebird from a programming language
PSQL (or Procedural SQL) is the extension for stored procedures, stored functions, triggers and execute block
Related
I have multiple select statements and I have to execute a particular select statement based on parameter we passed to script in Exasol.
This is pretty known to me in SQL server where we can achieve this functionality using inline function or stored procedure.
Exasol has a similar facility - it is called scripting in Exasol and is described in detail (with examples) in Section 3.5 of the Exasol User Manual. The manual can be downloaded from the Exasol website here :
https://www.exasol.com/portal/display/DOC/User+Manual+6.0
I learned the concept of prepared statements in JDBC in Java. So I think that prepared statement is a concept in JDBC, but not in RDBMS.
To see whether my guess is right, may I ask whether any major RDBMS provide the feature of prepared statements, in their PL/PSM like languages,such as PL/SQL, PL/pgSQL, MySQL, Transact-SQL?
If there is any such RDBMS, is prepared statement provided in SQL, or in PL/PSM like languages,such as PL/SQL, PL/pgSQL, MySQL, Transact-SQL?
I read DIfference Between Stored Procedures and Prepared Statements..?, but I can't find which provides the feature of prepared statements, although I think prepared statement is a concept in JDBC not in RDBMS, and stored procedure is a concept in RDBMS only.
Every implementation of SQL-compliant RDBMS should support an API for server-side prepared statements. I can't think of one RDBMS that doesn't support prepared statements.
JDBC has a class for PreparedStatement. The implementation varies by each brand of JDBC driver, but all those that I have used just delegate to the RDBMS API. The JDBC driver sends an SQL query string to the database server, and the SQL may contain parameter placeholders for example ? (some brands — like Oracle — support named parameters).
Some database implementations provide packages or functions you can use to execute a prepared statement, so you can create a query at runtime within a stored procedure.
Oracle: https://docs.oracle.com/cd/A57673_01/DOC/api/doc/PAD18/ch8.htm
Microsoft SQL Server: https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-prepare-transact-sql?view=sql-server-2017
Some database implementations also support PREPARE and EXECUTE statements that you can call as a query. This allows you to use prepared statements in a stored procedure or an SQL script.
MySQL: https://dev.mysql.com/doc/refman/8.0/en/sql-syntax-prepared-statements.html
PostgreSQL: https://www.postgresql.org/docs/10/static/sql-prepare.html
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!
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.
I have the displeasure of generating table creation scripts for Microsoft Access. I have not yet found any documentation describing what the syntax is for the various types. I have found the documentation for the Create Table statement in Access but there is little mention of the types that can be used. For example:
CREATE TABLE Foo (MyIdField *FIELDTYPE*)
Where FIELDTYPE is one of...? Through trial and error I've found a few like INTEGER, BYTE, TEXT, SINGLE but I would really like to find a page that documents all to make sure I'm using the right ones.
I've found the table in the link below pretty useful:
http://allenbrowne.com/ser-49.html
It lists what Access's Gui calls each data type, the DDL name, DAO name and ADO name (they are all different...).
Some of the best documentation from Microsoft on the topic of SQL Data Definition Language (SQL DDL) for ACE/Jet can be found here:
Intermediate Microsoft Jet SQL for Access 2000
Of particular interest are the synonyms, which are important for writing portable SQL code.
One thing to note is that the Jet 4.0 version of the SQL DDL syntax requires the interface to be in ANSI-92 Query Mode; the article refers to ADO because ADO always uses ANSI-92 Query Mode. The default option for the MS Access interface is ANSI-89 Query Mode, however from Access2003 onwards the UI can be put into ANSI-92 Query Mode. All versions of DAO use ANSI-89 Query Mode. I'm not sure whether SQL DDL syntax was extended for ACE for Access2007.
For more details about query modes, see
About ANSI SQL query mode (MDB)
This has it all. It's direct from MS, and actually tells you what the SQL datatype is that correlates to the GUI name.