Firebird - select field named start - sql

I've got a strange problem. A customer named a field in FirebirdSQL start. Now I cannot select this field:
select t.start from table t
Gives me the error: Invalid token
Any idea on how I can select this field?

The word start is a reserved word in Firebird and therefor needs to be quoted. The quote symbol in Firebird is the double quote. So you need to use:
select t."start" from "table" t
Note that I quoted table as well, as it is also a reserved word. Quoting makes the name case sensitive, so you may need to use "START" and "TABLE".
In your comments you mention that quoting yields a constant value 'table'. This means that you are using dialect 1, the deprecated (and legacy) dialect of Firebird. This legacy dialect cannot quote object names, and the double quote is for string literals (next to the SQL standard single quotes). Either your database is a dialect 1 database, or you specified the wrong connection dialect in your connection library.
If you database is actually dialect 3, solving this is as simple as specifying connection dialect 3 (or 0 to auto select based on the database dialect). However if your database is a dialect 1 database you will need to migrate to dialect 3 to be able to solve this.
If this is simply to try things out: make sure you create a dialect 3 database (for most tools this is the default).
How to determine database dialect
To determine the database dialect, you can use the gstat tool:
gstat mydatabase.fdb -header
In recent Firebird versions you can also query the MON$DATABASE monitoring table. Most query tools also allow you to view the database properties.
How to migrate from dialect 1 to dialect 3
That is I think too complicated to write down here (and I have never done it myself as it was considered deprecated years ago). However the Interbase 6.0 Getting Started (available from Firebird: Reference Manuals (at the end of the page) describes the basic process of migration, and I am sure that there are pages to be found with some googling.

Related

PostgreSQL - I get SQL Error [42P01] or [42703] if I don't add double quotes around table names or Fields

I'm using DBeaver to write script for my PostgreSQL database.
I have a PostgreSQL DB with Tables autogenerated by C#/EFCore (Microsoft ORM) - I receive SQL Error [42P01] if I don't add double quotes around table names when I cut and paste my ORM queries to DBeaver. I got [42703] for fields without double quotes. I do not have to add double quotes in C# code but it appears to be required in DBeaver?
example:
select * from Dnp3PropertyBase => SQL Error [42P01]
select * from "Dnp3PropertyBase" => OK, all results shown...
Does anybody know if I can change a parameter in DBeaver somewhere in order to enter table names and fields without double quotes?
Note: Using DBeaver 22.3.2 (latest on 2023-01-11)
Update After reading: Postgresql tables exists, but getting "relation does not exist" when querying
show search_path => public, public, "$user"
SELECT * FROM information_schema.tables => All tables are in public schema
SELECT * FROM information_schema.columns => All columns are in public schema
Question: How to be able to cut and paste my EFCore generated queries from Visual Studio output window to DBeaver query without having any errors regarding table names and field names?
First let me copy #a_horse_with_no_name comment:
Unquoted names are folded to lower case in Postgres (and to uppercase
in Oracle, DB2, Firebird, and many others). So SomeTable is in fact
stored as sometable (or SOMETABLE). However quoted identifiers have to
preserve the case and are case sensitive then. So "SomeTable" is
stored as SomeTable
Many peoples recommended me to go with snake case which I didn't want to go with initialy because all tables were auto generated by EF Core (Microsoft C# ORM). I told myself that Microsoft would do standard things. Microsoft use the exact "class" name in code as the table name , by default. That appears to me very logical in order to stay coherent and apply the same rules everywhere. C# recommended to use Camel case for classes so each table names end by default in Camel case instead of snake case.
PostgreSQL seems to promote users to use snake casing because they lower case every non double quoted names. According to a_horse_with_no_name, and I think the same, only PostgreSQL has the behavior of lower casing down every table names and field names which are not double quoted in SQL script. That behavior (changing casing for non double quoted names) appears to me as being very limitative. It also has hidden effect that could be hard to find for non initiated peoples coming from other DB world.
According to PostgreSQL doc, they recommend to use nuget package (.UseSnakeCaseNamingConvention()). It probably works fine for TPH (table per hierarchy) which is recommended by Microsoft for performance. But it does not works for table name for TPC (table per class) because of actual bugs in EFCore 7 (see Github project).
I received that message at the end of "update-database":
Both 'WindTurbine' and 'ResourceGenerator' are mapped to the table
'resource_generator'. All the entity types in a non-TPH hierarchy (one
that doesn't have a discriminator) must be mapped to different tables.
See https://go.microsoft.com/fwlink/?linkid=2130430 for more
information.
PostgreSQL doc : TPH supported OK but not for table in TPC (2023-01-12). I use TPC then I had to force each table name directly through TableAttribute.
My solution For table name, I use snake casing by manually add a "Table" attribute to each of my classes with the proper name like this sample:
[Table("water_turbine")]
public class WaterTurbine : ResourceGenerator
For fields, I use the EFCore.NamingConventions NugetPackage which works fine for fields names. Don't forget that if you have 2 classes mapped to the same object, it is because you are using TPC and did not force table name through TableAttribute.
This way all my table and fields names are snake casing and I can cut and paste any query dumped in my debugger directly in any SQL script window of DBeaver (or any SQL tool).

Is CARD a keyword in SQL? or: List of all SQL keywords

I'm adding a table to my database - CREATE TABLE dbo.Card - and SSMS is highlighting the word Card. I'm searching the internet trying to find out what that word means to SQL and if it is a keyword or not. I don't see it anywhere on Microsoft's list of SQL Reserved Words.
The main reason I care, aside from the highlighting bothering me, is that I want to avoid using any reserved words or keywords as schema/table/column/etc... names. When I absolutely have to - existing databases - I like to use square brackets to make things explicit.
Is Card a reserved word or keyword in SQL, or for any other reason unsafe to use as an identifier?
If it is safe to use, can anyone explain why SSMS is highlighting it?
If it is not 100% safe to use as a table name I'll most likely choose a different name.
Windows 8.1
SSMS v17.7
Red Gate - Up to date, including SQL Prompt 9.4.9
SQL Server 2017 (14.0)
Database Compatibility Level 2017 (140)
UPDATE
It looks like the main consensus is:
It is not a reserved or keyword
SSMS highlights it because reasons... It's probably used somewhere by MS SQL Server or SSMS
At this point I'm just terribly curious, but at least I know there's no need to worry. Thanks everyone for your answers.
No, card is not a reversed word in Microsoft SQLServer or SQL ANSI standard.
Card is definitely not a reserved keyword in SQL Server
You can check the complete list of reserved words Reserved Keywords (Transact-SQL)
SSMS highlights it because reasons... It's probably used somewhere by
MS SQL Server or SSMS
They are various keywords that have been subjectively chosen by Microsoft and placed into a list within the query editor syntax coloring file.
I suggest it's always good to use Delimited Identifiers ([] or ") when specifying table name and column names.
For example, the script you are using should be written as
CREATE TABLE [dbo].[Card](<Columns>)

Is SELECT INTO T-SQL?

I'm working in a project where I have been explicitly required to not use T-SQL syntax. The application we are using supports T-SQL but we are not allowed to use it to avoid potential migration issues.
My question is: is the SELECT ... INTO statement T-SQL or SQL? If it is T-SQL, is there a specific SQL query to copy an existing table into a new one? (I have tried with CREATE TABLE AS .. FROM but it doesn't work).
Sounds like a very basic question but I haven't been able to find the answer anywhere. Thus, in addition to the question above, it would be very helpful to know if there is a guide/dictionary/website that collects only the standard SQL syntax.
Thanks!
I think they recommend you to use ANSI SQL, instead of T-SQL (SQL Server) or PL-SQL (ORACLE). Considering it as common requirement, every database vendor provide their own way of implementing this requirement. When you use ANSI SQL, you will not have migration issues, when you move from one database vendor to another database vendor.
SQL SERVER
SELECT * INTO new_table
FROM existing_table
ORACLE & ANSI-SQL
CREATE TABLE new_table
AS SELECT * FROM existing_table
is SELECT INTO TSQL or SQL?
Neither. The MySQL documentation claims that SELECT INTO is a Sybase extension to standard sql. As such I don't think you can accurately say it's either of these, but you can say that it's neither. It is indeed used in T-SQL, as well as some other database vendor products, to create a table from a query. The SQL standard says that queries with that goal should be formed as CREATE TABLE blah AS SELECT .... Oracle/MySQL, for example, use the standard form though you can see them use SELECT INTO in a different context, to assign data to variables in stored procedures
If you want to avoid use of this non standard syntax when creating and populating a table then you'll have to:
CREATE TABLE blah (column spec to match query output)
INSERT blah (select query here)
But then you run into nuances like "sqlserver calls it datetime/datetime2 but oracle calls it date/timestamp"
And ultimately you'll probably get into a situation where you just can't use one form of sql to do all you want..
I'd imagine most libraries that do data access on multiple underlying databases have mechanisms to use vendor specific terminology where required
From the answers, it appears you might need to specify which SELECT INTO you're talking about. The other answers seem to suggest there exists some kind of SELECT ... INTO <table-name> when there is also a kind of SELECT ... INTO <local-variable-name list>. The latter is used in embedded SQL for making SQL interact with variables of the host language program. I'm not certain but that variant may also be used in the part of the SQL language that deals with procedures written in SQL (the SQL/PSM part of the standard).
A "reference" that covers "only the standard SQL syntax" is, in principle, the ISO standard document itself, only available by purchase from ISO (and yes, it's ISO not ANSI - ANSI does nothing more than rubberstamping the ISO document after removing all the names of non-US contributors). And not the easiest kind of literature. There are "draft" versions floating around on the internet that might deviate from the published final standards. E.g. http://www.wiscorp.com/sql200n.zip. Note that this is a SQL:2008 draft. Current standard version is SQL:2011. And it's several thousands of pages, so I guess that covers your question "Is all the syntax covered in w3schools standard SQL". (Hint : no)

What is the universal method to escape keywords in SQL query?

If my query is
SELECT from FROM myTable;
How can I escape column name 'from'.
I need a way which is applicable to Oracle, MySQL, Teradata and all other systems
Will
SELECT myTable.from FROM mytable;
work on all systems?
The SQL standard is pretty clear: reserved keywords can only be used when they are enclosed in double quotes:
select "FROM" from mytable;
Note that a quoted identifier are also case sensitive. "Foo" and "FOO" are two different names! (whereas Foo and FOO are the same names in standard SQL and most DBMS)
I need a way which is applicable to Oracle, MySQL, Teradata and all other systems
Postgres, Oracle, DB2 (LUW), Firebird, Ingres, HSQLDB, H2, Vertica, HANA and Teradata comply with the standard out of the box.
MySQL needs to convinced to respect the standard by setting sql-mode to ANSI or at least ANSI_QUOTES.
For SQL Server the option QUOTED_IDENTIFIER needs to be set to on.
For Informix you need to set DELIMIDENT to y when connecting through JDBC
But in general you should really avoid the need to use quoted identifiers. Typically you will get in trouble sooner or later by doing that.
Universal method??? not sure about any such but double quote "" is ANSI standard other than that every RDBMS has some specific way of doing so. Moreover you don't need any such universal way if you refrain yourself from using reserve word or keyword for table or column name .. as already suggested in comment

visual studio 2012 query builder

Can anybody tell me what does the error mean? Whenever I open the query builder it will prompt with an error indicating that SQL syntax errors were encountered.
https://msdn.microsoft.com/en-us/library/ms189012.aspx
I looked at the following page in MSDN but I don't understand what it means...
For instance, what do these bullet points from the MSDN article mean?
The SQL statement is incomplete or contains one or more syntax errors.
The SQL statement is valid but is not supported in the graphical panes (for example, a Union query).
The SQL statement is valid but contains syntax specific to the data connection you are using.
USER (which you've apparently decided is an appropriate table name) is a SQL Server reserved word.
The best solution is to rename your table, so you don't have to escape the table name every time you want to query it and to make it clear it's your user data (hey, there's a table name suggestion - userdata).
The other option is to escape the name by surrounding it with square brackets:
SELECT * FROM [users]
Note that it will get old fast having to do this with every query. Again, the best solution would be to rename the table to something that isn't a reserved word.