Problem arises when filtering string columns with symbols '-'.
For example query bellow returns ~280 rows:
"SELECT code FROM client WHERE code >= 'M-SOLUTIONS' AND code <= 'MUZIKOS'"
but CR with record selection bellow only returns 20 rows:
{client.code} >= 'M-SOLUTIONS' AND {client.code} <= 'MUZIKOS'
If I put 'Lxxx' instead of 'M-SOLUTIONS' then returned data is correct. Any ideas how to overcome this issue? I used PostgreSql database over Odbc connection.
Apparently they use different collations. Some collations will ignore punctuation on a first pass, using it only if the values are otherwise equal. Figure out which collation you want to use, then make sure both CR and PostgreSQL use that one.
Related
I need to convert the name of the table into lower before passing it for the query.
Irrespective of which case in pass the value for parameter $1 i need it to be converted into lower case before executing the below query.
QUERY:
show tables like '$1';
I have tried something like
QUERY
show tables like 'lower($1)';
But this doesn't work.
please help.
Your response would be highly appreciated
Impala identifiers are always case-insensitive. That is, tables named
t1 and T1 always refer to the same table, regardless of quote
characters. Internally, Impala always folds all specified table and
column names to lowercase. This is why the column headers in query
output are always displayed in lowercase.
Impala Documentation
All the below queries will give same result as internally impala converts to lowercase.
show tables like 'test*';
show tables like 'TeSt*';
show tables like 'TEST*';
I am having to create a second header line and am using the first record of the Query to do this. I am using a UNION All to create this header record and the second part of the UNION to extract the Data required.
I have one issue on one column.
,'Active Energy kWh'
UNION ALL
,SUM(cast(invc.UNITS as Decimal (15,0)))
Each side are 11 lines before and after the Union and I have tried all sorts of combinations but it always results in an error message.
The above gives me "Error converting data type varchar to numeric."
Any help would be much appreciated.
The error message indicates that one of your values in the INVC table UNITS column is non-numeric. I would hazard a guess that it's either a string (VARCHAR or similar) column or something else - and one of the values has ended up in a state where it cannot be parsed.
Unfortunately there is no way other than checking small ranges of the table to gradually locate the 'bad' row (i.e. Try running the query for a few million rows at a time, then reducing the number until you home in on the bad data). SQL 2014 if you can get a database restored to it has the TRY_CONVERT function which will permit conversions to fail, enabling a more direct check - but you'll need to play with this on another system
(I'm assuming that an upgrade to 2014 for this feature is out of the question - your best bet is likely just looking for the bad row).
The problem is that you are trying to mix header information with data information in a single query.
Obviously, all your header columns will be strings. But not all your data columns will be strings, and SQL Server is unhappy when you mix data types this way.
What you are doing is equivalent to this:
select 'header1' as col1 -- string
union all
select 123.5 -- decimal
The above query produces the following error:
Error converting data type varchar to numeric.
...which makes sense, because you are trying to mix both a string (the header) with a decimal field.
So you have 2 options:
Remove the header columns from your query, and deal with header information outside your query.
Accept the fact that you'll need to convert the data type of every column to a string type. So when you have numeric data, you'll need to cast the column to varchar(n) explicitly.
In your case, it would mean adding the cast like this:
,'Active Energy kWh'
UNION ALL
,CAST(SUM(cast(invc.UNITS as Decimal (15,0))) AS VARCHAR(50)) -- Change 50 to appropriate value for your case
EDIT: Based on comment feedback, changed the cast to varchar to have an explicit length (varchar(n)) to avoid relying on the default length, which may or may not be long enough. OP knows the data, so OP needs to pick the right length.
I have written some basic SQL in Oracle, which runs as expected. It selects a client, their ID and what 'services' they can provide.
However, when I add variables that are passed from VBA code the error message ORA-00907: Missing Right Parenthesis occurs. It is due to an OR in the code.
AND C.CURRENCY LIKE :cmbSelectAccountCcy
AND (S.SERVICEID LIKE :cmbSelectServiceType OR S.SERVICEID LIKE :cmbSelectServiceType2)
AND .... etc
If I remove the OR it runs as expected. The OR is part of a check that includes (at the end)
HAVING COUNT(S.SERVICEID) > 2
Allowing the 2 values to be checked, and only if the 2 (or more) are present display the client.
The combo boxes in Excel will pass the service ID as either a set value from the drop down box, or a % character. I assume the right parenthesis is never reached in some cases.
What is the reason that I can run the SQL query with Hard Coded values, but not passing the very same variables through VBA? I have a Debug.Print() statement in the VBA which is showing all the values I would expect to see passed over.
UPDATE:
Changing the name cmbSelectServiceType2 to cmbServiceTypeTwo appears to have fixed the issue but, as of yet, I cannot figure out why. Any answers appreciated still! The only factor I can see is that the first is 21 chars, the second is < 20 chars. The column data type is VARCHAR2 in the table.
Tangent: The OR statement is now returning Service1 or Service1 and Service2 or Service2, i.e. a fully OR statement. The HAVING clause above was an attempt to impose that only BOTH are allowed.
UPDATE 2
Changing the '2' in cmbSelectServiceType2 to letters 'two' does not work. It seems like 20 chars is some arbitrary limit.
according to:
Getting around the Max String size in a vba function?
A vba function cannot handle a string with more than 255 chars, is it possible that this may be causing the problem, especially as when you cut the string length it works.
I am not very familiar with iseries/DB2. However, I work on a website that uses it as its primary database.
A new column was recently added to an existing table. When I view it via AS400, I see the following data type:
Type: S
Length: 9
Dec: 2
This tells me it's a numeric field with 6 digits before the decimal point, and 2 digits after the decimal point.
When I query the data with a simple SELECT (SELECT MYCOL FROM MYTABLE), I get back all the records without a problem. However, when I try using a DISTINCT, GROUP BY, or ORDER BY on that same column I get the following exception:
[SQL0802] Data conversion of data mapping error
I've deduced that at least one record has invalid data - what my DBA calls "blanks" or "4 O". How is this possible though? Shouldn't the database throw an exception when invalid data is attempted to be added to that column?
Is there any way I can get around this, such as filtering out those bad records in my query?
"4 O" means 0x40 which is the EBCDIC code for a space or blank character and is the default value placed into any new space in a record.
Legacy programs / operations can introduce the decimal data error. For example if the new file was created and filled using the CPYF command with the FMTOPT(*NOCHK) option.
The easiest way to fix it is to write an HLL program (RPG) to read the file and correct the records.
The only solution I could find was to write a script that checks for blank values in the column and then updates them to zero when they are found.
If the file has record format level checking turned off [ie. LVLCHK(*NO)] or is overridden to that, then an HLL program. (ex. RPG, COBOL, etc) that was not recompiled with the new record might write out records with invalid data in this column, especially if the new column is not at the end of the record.
Make sure that all programs that use native I/O to write or update records on this file are recompiled.
I was able to solve this error by force-casting the key columns to integer. I changed the join from this...
FROM DAILYV INNER JOIN BXV ON DAILYV.DAITEM=BXV.BXPACK
...to this...
FROM DAILYV INNER JOIN BXV ON CAST(DAILYV.DAITEM AS INT)=CAST(BXV.BXPACK AS INT)
...and I didn't have to make any corrections to the tables. This is a very old, very messy database with lots of junk in it. I've made many corrections, but it's a work in progress.
I have a really weird issue with Sql queries on unicode data. Here's what I've got:
Sql Server Express 2008 R2 AS
Table containing chinese characters/words/phrases (100,000 rows)
When I run the following, I get the correct row + 36 other rows returned... when it should only be the one row:
SELECT TOP 1000 [ID]
,[MyChineseColumn]
,UNICODE([MyChineseColumn])
FROM [dbo].[MyTableName]
WHERE [MyChineseColumn]= N'㐅'
As you'd expect, the row with 㐅 is returned, but also the following: 〇, 宁, 㮸 and a bunch of others...
Anyone have any ideas what is going on here? This has really got me confused and I am not sure how to solve this one (tried "Googling" already)...
Thanks
Please check the column is using an appropriate Chinese collation as that will determine the semantics used in this type of comparison.
You may want to try and use a binary collation, these characters seem to be somehow matched as identical (possibly by ignoring case and/or accents, depending on the used collation).