Can somebody please tell me what is the problem with the following informix statement :
SELECT * FROM
(some big query here)
INTO EXTERNAL empdata(selected_date date, land char, grund integer, some_user varchar, nr decimal(15))
USING (DATAFILES("DISK:/usr1/tbodan.out"))
I get a syntax error near INTO EXTERNAL empdata.
UPDATE
Informix version is 11.7 and omitting the column definition only brings the following error Error: Virtual column must have explicit name.
You need to follow the documented syntax at INTO EXTERNAL clause.
I think your problem is that you tried to provide column names and data types for the table.
This SQL worked for me:
SELECT * FROM elements
INTO EXTERNAL ext_elements
USING (DATAFILES("DISK:/Users/jleffler/tmp/ext-elements.table"))
This SQL did not, generating a -201 "A syntax error has occurred" error:
SELECT * FROM elements
INTO EXTERNAL ext_elements(atomic_number INTEGER, symbol CHAR(3),
name CHAR(20), atomic_weight DECIMAL(8,4),
pt_period SMALLINT, pt_group CHAR(2), stable CHAR(1))
USING (DATAFILES("DISK:/Users/jleffler/tmp/ext-elements.table"))
Testing on a Mac running macOS Sierra 10.12.5, using Informix 12.10.FC4.
Ok,so the problem was actually in the select query.
The query returns more columns that do not have an explicit name and are tagged as "expression" that is why the Error: Virtual column must have explicit name. popped up.
I solved this by using aliases for those columns. Then used the syntax suggested here.
Related
A fragment of SQL in the Informix dialect
SELECT INSUREDNAME
FROM sc5100car3gdb#idp_5100_cb:PRPCINSURED P
WHERE P.PROPOSALNO = A.PROPOSALNO
What does this grammar mean?
The SQL fragment is:
SELECT INSUREDNAME
FROM sc5100car3gdb#idp_5100_cb:PRPCINSURED P
WHERE P.PROPOSALNO = A.PROPOSALNO
This means that there is a table PRPCINSURED in database sc5100car3gdb hosted on Informix server idp_5100_cb; inside the query, the table will be referred to by the alias P. It has columns INSUREDNAME and PROPOSALNO. Further, this must be a fragment of an SQL statement. The WHERE clause uses the alias P, but also references another table with the alias (or perhaps name) A. However, the context defining A is not shown; as it stands, the A will trigger an error. (When I ran an analogous query, I got the error SQL -217: Column (a) not found in any table in the query (or SLV is undefined).)
See the Informix Guide to SQL: Syntax manual on database object names for more information about the notation used for the table name.
I have the following as part of an AR query:
.having('COUNT(foo.id) > bar.maxUsers')
This generates an error:
ActiveRecord::StatementInvalid:
PG::UndefinedColumn: ERROR: column bar.maxusers does not exist
^
HINT: Perhaps you meant to reference the column "bar.maxUsers".
I am referencing the column bar.maxUsers.
So, apparently AR downcases the query. How to suppress this behavior?
Rails 4.2.10
PostgreSQL
EDIT: SQL:
SELECT ... HAVING COUNT(foo.id) > bar.maxUsers
So it is happening after the to_sql. Maybe from the execute?
This isn't an ActiveRecord or AREL issue, this is just how case sensitivity works in SQL and PostgreSQL.
Identifiers in SQL (such as table and column names) are case-insensitive unless they're quoted. Standard SQL says that unquoted identifiers are folded to upper case, PostgreSQL folds them to lower case, hence the bar.maxusers in the error message.
The solution is to quote the offending column name:
.having('COUNT(foo.id) > bar."maxUsers"')
Note that you must use double quotes for quoting the identifier as single quotes are only for string literals. Also note that identifier quoting is database-specific: standard SQL and PostgreSQL use double quotes, MySQL uses backticks, SQL Server uses brackets, ...
I am currently trying to do a complicated WHERE search on a table using Rails, the trouble is I get the error:
PG::Error: ERROR: column "email" does not exist
LINE 1: SELECT "bans".* FROM "bans" WHERE (Email='' AND IP='' AND (...
^
: SELECT "bans".* FROM "bans" WHERE (Email='' AND IP='' AND (Username='NULL' ))
And I know that column actually exists, and doing a rails dbconsole gives me the following:
Jungle=> select * from bans;
id | Username | IP | Email | Reason | Length | created_at | updated_at
----+----------+----+-------+--------+--------+------------+------------
(0 rows)
So this is definatly in the database, has anyone had any experience with this?
SQL column names are case insensitive unless quoted, the standard says that identifiers should be normalized to upper case but PostgreSQL normalizes to lower case:
Quoting an identifier also makes it case-sensitive, whereas unquoted names are always folded to lower case. For example, the identifiers FOO, foo, and "foo" are considered the same by PostgreSQL, but "Foo" and "FOO" are different from these three and each other. (The folding of unquoted names to lower case in PostgreSQL is incompatible with the SQL standard, which says that unquoted names should be folded to upper case. Thus, foo should be equivalent to "FOO" not "foo" according to the standard. If you want to write portable applications you are advised to always quote a particular name or never quote it.)
You're referencing Email in your SQL:
SELECT "bans".* FROM "bans" WHERE (Email='' ...
but PostgreSQL is complaining about email:
column "email" does not exist
Your unquoted Email is being treated as email because PostgreSQL normalizes identifiers to lower case. Sounds like you created the columns with capitalized names by double quoting them:
create table "bans" (
"Email" varchar(...)
...
)
or by using :Email to identify the column in a migration. If you quote a column name when it is created, then it is not normalized to lower case (or upper case in the SQL standard case) and you'll have to double quote it and match the case forever:
SELECT "bans".* FROM "bans" WHERE ("Email"='' ...
Once you fix Email, you'll have the same problem with IP, Username, Reason, and Length: you'll have to double quote them all in any SQL that references them.
The best practise is to use lower case column and table names so that you don't have to worry about quoting things all the time. I'd recommend that you fix your table to have lower case column names.
As an aside, your 'NULL' string literal:
SELECT "bans".* FROM "bans" WHERE (Email='' AND IP='' AND (Username='NULL' ))
-- -------------------->------------------>---------->---------------^^^^^^
looks odd, are you sure that you don't mean "Username" is null? The 'NULL' string literal and the NULL value are entirely different things and you can't use = or != to compare things against NULL, you have to use is null, is not null, is distinct from, or is not distinct from (depending on your intent) when NULLs might be in play.
It doesn't look like you're error is from a test database but if so try rake db:test:prepare.
In general, be aware that you have 3 databases - Test, Development, Production. So it's easy to get them mixed up and check the wrong one.
I had the same problem here,
but as mu-is-too-short said, PostgreSql can be told to
search with case sensitivity on columns names.
So by implemented this code I managed to bypass the same error that you're facing:
Transaction.find(:all,:conditions => ["(date between ? and ?) AND \"Membership_id\" = ?", Time.now.at_beginning_of_month, Time.now.end_of_month,membership.id])
Noticed the \" sign srrounding the column name? Well.. as annoying as it is, that's the fix to this problem.
I have a note field of string type in one of my models in my sqlite3 database, but I realized that I needed to store more text than string would allow.
I just ran a migration changing the type of the field from string to text. Looking at my database, it says that the type is now text(255), whereas before it was varchar(255).
What does the 255 mean? Is that a character limit? If so, would I have the same storage problems as before? How would I fix this?
Here is the migration I used to change the field type
change_column(:posts, :note, :text)
SQLite does not enforce text storage limits. If you declare a column VARCHAR(1) or TEXT(1) you still can store some very long blob of 500 Megabytes inside it. Even though that is not adviseable.
~$ sqlite
SQLite version 3.7.2
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> create table foo ( bar text(3));
sqlite> insert into foo values ('aeiou');
sqlite> select * from foo;
aeiou
You should just make your storage type text and not put any limit on it. The 255 denotes the maximum number of characters allowed in the field.
I am using AR's sum method for a query and seeing this error when using PostgreSQL:
PGError: ERROR: function sum(character varying) does not exist
LINE 1: SELECT sum("assets".asset_file_size) AS sum_asset_file_size ...
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
SELECT sum("assets".asset_file_size) AS sum_asset_file_size FROM "assets" [0m
I am using the following in my code, which works with MySQL:
Asset.sum(:asset_file_size)
I am trying to get a sum of the asset_file_size column.
What am I missing here?
OH.
In writing my question I worked out this issue.
I had accidentally made the column Varchar rather than an Integer. Hence the request to "explicitly type cast".
We apologise for the incovenience.