Pervasive database: Problem with spaces in column names - odbc

We use pervasive Database with Zen Contol-Center And want to perform the following SQl-Statenemt:
insert into MWlog
(Signatur,Datum,Uhrzeit,Auftrag,Probe,Parameter,Matrix,`Messwert neu`,Zugriff,`Messwert alt`,Aenderungsgrund)
values
('ML','2020-12-01','15:04:50','230176','230176','Bas. wirk.','TM','5.62','5','5.62','Neuer Import')
We get the following error-message:
*<<<<<<<<<<<<<<<<<<<<<<<<
insert into MWlog(Signatur,Datum,Uhrzeit,Auftrag,Probe,Parameter,Matrix,`Messwert neu`,Zugriff,`Messwert alt`,Aenderungsgrund) values ('ML','2020-12-01','15:04:50','230176','230176','Bas. wirk.','TM','5.62','5','5.62','Neuer Import')
[Zen][SQL Engine]
Syntax Error: insert into MWlog(Signatur,Datum,Uhrzeit,Auftrag,Probe,Parameter,Matrix,<< ??? >>`Messwert neu`,Zugriff,`Messwert alt`,Aenderungsgrund) values ('ML','2020-12-01','15:04:50','230176','230176','Bas. wirk.','TM','5.62','5',
>>>>>>>>>>>>>>>>>>>>>>>>*
What is wrong in the SQL Statement?
(We found out that the problem are the spaces in the field-Names)
We are using
Zen Control Center
Zen Install Version 14.10.035.
Java Version 1.8.0_222.

Gord Thompson is correct. You need to use double quotes around field names with spaces or field names that are reserved key words. You statements should be:
insert into MWlog
(Signatur,Datum,Uhrzeit,Auftrag,Probe,Parameter,Matrix,"Messwert neu",Zugriff,"Messwert alt",Aenderungsgrund)
values
('ML','2020-12-01','15:04:50','230176','230176','Bas. wirk.','TM','5.62','5','5.62','Neuer Import')

Related

What syntax am I missing?

I am a completely new to SQL and I am follow a tutorial verbatim to try and create a new table in my first database. However I am getting the following error.
USE menu;
CREATE TABLE Burgers
(
`Burger Number` TINYINT,
Burger VARCHAR(50),
Price DECIMAL(5,2),
Description VARCHAR(300),
);
Yields SQL Error 1064:
SQL Error (1064): You have an errror in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ')' at line 8
I made sure to use commas to separate each column and used parenthesis to what I understand is the proper way to do so. I am not sure if version is relevant but I am using version 10.5.8 of MariaDB. Any insight is appreciated!
You have one comma too many.
...
Description VARCHAR(300),
);
You need commas between each column, index, or constraint within the CREATE TABLE statement, except for the last one before the closing parenthesis.
It should be like this:
...
Description VARCHAR(300)
);
General tip about syntax errors: They tell you exactly where to look for the problem, because it reports the place in your SQL statement where the syntax parser got confused.
In this case it reported:
...right syntax to use near ')' at line 8
This tells you the problem is at that point in the syntax. The ) didn't belong there, because the syntax was expecting something else. Because commas separate columns, it was expecting another column definition following a comma.

Mysql table collation change

I have an old table with several Spanish keywords. Its collation is latin1_swedish_ci.
The column with the keywords has a Primary index.
When I try to change collation to utf8_general_ci it is not possible because if finds duplicates.
With that index it is not possible.
What happens is that, for example, "cañada" is taken as "canada" that already exists but they are different words.
That was using phpMyAdmin.
Another try was to export the table as file.sql and using
sed 's/STRING_SOURCE/STRING_REPLACE/'
but at the end mysql source gave me the same error (did expect that :))
I also try that last one with the entire database.
MySQL version 5.5.64-MariaDB
phpMyAdmin, selected the database/table, tab Structure, column with the keywords selected Change and finally from the drop down Collation I selected ut8_general_ci
How can I make this change keeping all the keywords?
Since you are focused on Spanish, use a Spanish collation, not a generic one: utf8_spanish_ci and utf8_spanish2_ci. They treat ñ as a separate letter between n and o. Other collations treat ñ and n as the same.
Meanwhile, ç=c.
However ll is treated as two l by utf8_spanish_ci, while it is treated as coming after lz by utf8_spanish2_ci. (Something about dictionary versus phonebook -- remember those artifacts from ancient history?)
Ref: http://mysql.rjweb.org/utf8_collations.html
Once you upgrade to 8.0, there will be two more choices: utf8mb4_es_0900_ai_ci and utf8mb4_es_trad_0900_ai_ci.
Ref: http://mysql.rjweb.org/utf8mb4_collations.html

teradata : to calulate cast as length of column

I need to use cast function with length of column in teradata.
say I have a table with following data ,
id | name
1|dhawal
2|bhaskar
I need to use cast operation something like
select cast(name as CHAR(<length of column>) from table
how can i do that?
thanks
Dhawal
You have to find the length by looking at the table definition - either manually (show table) or by writing dynamic SQL that queries dbc.ColumnsV.
update
You can find the maximum length of the actual data using
select max(length(cast(... as varchar(<large enough value>))) from TABLE
But if this is for FastExport I think casting as varchar(large-enough-value) and postprocessing to remove the 2-byte length info FastExport includes is a better solution (since exporting a CHAR() will results in a fixed-length output file with lots of spaces in it).
You may know this already, but just in case: Teradata usually recommends switching to TPT instead of the legacy fexp.

Bracket-escaped table names with dplyr

I'm programmatically fetching a bunch of datasets, many of them having silly names that begin with numbers and have special characters like minus signs in them. Because none of the datasets are particularly large, and I wanted the benefit R making its best guess about data types, I'm (ab)using dplyr to dump these tables into SQLite.
I am using square brackets to escape the horrible table names, but this doesn't seem to work. For example:
data(iris)
foo.db <- src_sqlite("foo.sqlite3", create = TRUE)
copy_to(foo.db, df=iris, name="[14m3-n4m3]")
This results in the error message:
Error in sqliteSendQuery(conn, statement, bind.data) : error in statement: no such table: 14m3-n4m3
This works if I choose a sensible name. However, due to a variety of reasons, I'd really like to keep the cumbersome names. I am also able to create such a badly-named table directly from sqlite:
sqlite> create table [14m3-n4m3](foo,bar,baz);
sqlite> .tables
14m3-n4m3
Without cracking into things too deeply, this looks like dplyr is handling the square brackets in some way that I cannot figure out. My suspicion is that this is a bug, but I wanted to check here first to make sure I wasn't missing something.
EDIT: I forgot to mention the case where I just pass the janky name directly to dplyr. This errors out as follows:
library(dplyr)
data(iris)
foo.db <- src_sqlite("foo.sqlite3", create = TRUE)
copy_to(foo.db, df=iris, name="14M3-N4M3")
Error in sqliteSendQuery(conn, statement, bind.data) :
error in statement: unrecognized token: "14M3"
This is a bug in dplyr. It's still there in the current github master. As #hadley indicates, he has tried to escape things like table names in dplyr to prevent this issue. The current problem you're having arises from lack of escaping in two functions. Table creation works fine when providing the table name unescaped (and is done with dplyr::db_create_table). However, the insertion of data to the table is done using DBI::dbWriteTable which doesn't support odd table names. If the table name is provided to this function escaped, it fails to find it in the list of tables (the first error you report). If it is provided escaped, then the SQL to do the insertion is not synatactically valid.
The second issue comes when the table is updated. The code to get the field names, this time actually in dplyr, again fails to escape the table name because it uses paste0 rather than build_sql.
I've fixed both errors at a fork of dplyr. I've also put in a pull request to #hadley and made a note on the issue https://github.com/hadley/dplyr/issues/926. In the meantime, if you wanted to you could use devtools::install_github("NikNakk/dplyr", ref = "sqlite-escape") and then revert to the master version once it's been fixed.
Incidentally, the correct SQL-99 way to escape table names (and other identifiers) in SQL is with double quotes (see SQL standard to escape column names?). MS Access uses square brackets, while MySQL defaults to backticks. dplyr uses double quotes, per the standard.
Finally, the proposal from #RichardScriven wouldn't work universally. For example, select is a perfectly valid name in R, but is not a syntactically valid table name in SQL. The same would be true for other reserved words.

swi-prolog odbc error while inserting into postgresql

I have the following problem and I'm begging for help: I'm using swi-prolog and odbc interface to connect to postgresql database. Problem occurs when I try to insert in database. SELECT works fine but INSERT doesn't work. Does anybody know what am I doing wrong.
Here's my simple test code:
:-use_module(library(odbc)).
connect(C):-
odbc_connect(baza, C, [user(Mat),
password(lozinka), alias(baza), open(once)]).
sel(R) :-
odbc_query(baza,
'SELECT * FROM pacijent',
R).
ins:-
odbc_query(baza, 'INSERT INTO pacijent (name, surname, passw, number) VALUES ("James", "Bond", 007, 007)').
This is the error when i try to insert:
?- ins.
ERROR: ODBC: State S1000: [unixODBC]ERROR: column "James" does not exist at character 30;
Error while executing the query
Also i tried to insert through psql console and everything works fine, but as said problem is when inserting from prolog.
Please help, im stuck here.
Thanks
A suggestion: proper escaping, don't know if it'll be enough though. I'd turn
"James", "Bond"
into
\'James\', \'Bond\'
The problem is you've passed the column data for columns name and surname in double quotes instead of single quotes. Most databases use " (double quotes) for identifiers like table and column names and ' (single quotes) for data. How you ensure that in prolog I don't know.
I suspect you'll want to quote the other 2 columns as well.
In ODBC you'd use SQLGetInfo and get SQL_IDENTIFIER_QUOTE_CHAR which will usually return double quotes meaning to quote identifiers use these quotes.

Resources