This code gives an error. I have looked similar type questions and couldn't find the answer.
sum(COALESCE(((rpt.report_target_data::json->>'itemQuantity')::int)::int),0) as itemQuantity,
report_target_data is a json object and 'itemQuantity' is an element of that json. Sometimes that field contains an empty value. So when I try to get the sum it gives an error because postgres cannot get the sum if a column had a empty value. What is the wrong with the above code. It there a way to walk around that matter? Is there a way to calculate sum even if some rows contain empty values?
Here is the error of the above code ->
No function matches the given name and argument types. You might need to add explicit type casts.
In my case, it was not a COALESCE problem but I ended up in this question.
I noticed that my column values were characters (the varchar type) so what I did is:
select sum(cast(num_suf as int)) as total from results;
Just in case someone lands in this question again :)
Related
I'm trying to convert the date field from YYYY-MM-DD HH:MM:SS:MS to MM/DD/YYYY format in a view using Snowflake database with below condition:
TO_VARCHAR(DATE(SRC_DATE),'MM/DD/YYYY')
I'm able to convert the date to expected format with above condition, but when I try to load data from this view to different table using a sp its failing with below error:
Failed: Code: 939 - State: 22023 - Message: SQL compilation error: error line 1 at position 1,058
too many arguments for function [TO_VARCHAR(VALID_FROM_DATE, 'YYYYMMDDHH24MISS.FF9')] expected 1, got 2 - Stack Trace: Statement.execute, line 9 position 58
Need help in getting the right logic to fix this error. How can I do this?
You just need to do:
TO_VARCHAR(SRC_DATE,'MM/DD/YYYY')
I’m wondering why you are trying to change the format of a date in Informatica? A date is held as a number, the format is just how it is displayed - the underlying number doesn’t change
I'm not sure exactly what's going on yet, but I can walk through some things we do know.
First, the error message says the TO_VARCHAR() function only expected one argument. Knowing this we can look at the documentation for the method. Here we see there are several overloads:
TO_VARCHAR( <expr> )
TO_VARCHAR( <numeric_expr> [, '<format>' ] )
TO_VARCHAR( <date_or_time_expr> [, '<format>' ] )
TO_VARCHAR( <binary_expr> [, '<format>' ] )
Only one of these overloads (the first) fits the error message. Most of the overloads allow multiple arguments, but only if the first argument matches certain types: numeric, date/time, or binary. This does include the expected date result of the DATE() function
Therefore we can conclude somehow the result of the DATE(SRC_DATE) call is NOT a valid <date_or_time_expr> in every case, such that we at least sometimes end up with the first overload.
While the documentation for Date() does allow several ways for the function to return NULL, it also explicitly returns a Date type:
The data type of the returned value is DATE.
Thus I'd still expect it to always match the third overload above. The only other possible result from Date() is the conversion fails, in which case we'd see a different error message entirely.
The best explanation I could guess at is the return type for Date() doesn't matter if the result is NULL (that is: NULL is inherently untyped for this purpose), such that you're still ending up with the first overload, which does not allow the 2nd argument.
You could possibly fix this by adding a COALESCE() so NULL is converted to a valid consistent throw-away date expression; something like, say, 1900-01-01. If it's important to preserve NULL values you can then in turn also wrap the whole thing in a NULLIF() call.
Finally, all of this only make sense is SRC_DATE is not already a valid <date_or_time_expr>. That is, if it's something like a varchar column. This in itself would already be a mistake in schema design. On the other hand, if it is already a datetime column, there is no need at all to call Date(), and it can be used directly with TO_VARCHAR()... but with likely the same caveat about NULL values you're already seeing.
We can test this theory by trying the following:
TO_VARCHAR(DATE(IFNULL(SRC_DATE,'1900-01-01')),'MM/DD/YYYY')
I am running a query on a db table which is returning one record when I expect it to return no records.
SELECT yeargroupID FROM tbl_yeargroup WHERE yeargroup='S' AND schoolID=2.
The yeargroup field is a tinyint field. Thefore the WHERE clause is looking the letter 'S' in the numeric field, so should not find anything. Yet it returns the record with the yeargroup = 0, and yeargroupID=17 (the bottom record in the table)
I'm confused as to why it is returning this record and how to avoid it.
Thanks
This logic, as you have pointed out, is comparing a number and a string:
WHERE yeargroup = 'S'
Handling such situations is an important part of most SQL compilers, and it is well documented. The solution is to implicitly convert values to "conforming" types. This is sad. My preference would be for the compiler to generate an error and force the user to use correct types. I find that implicit conversion creates more problems than it solves.
In any case, the rules in this case are pretty simple. The string is converted to an integer. But, how is a string with no digits converted? Well, the rule in MySQL is that the leading digits are converted to a number. And if there are none, the value is 0. So, this turns into:
where yeargroup = 0
You can see the results more clearly if you run:
select 'S', 'S' + 0
Note that most databases would return an error in this case (a type conversion error). But even those would accept the string if it looked like a number, so this would be allowed:
where yeargroup = '5'
What is the proper solution? Never mix types. Do not construct queries by munging constant values. Instead, queries from an application should always be using parameters.
I have a query where i am trying to update field by taking the left number of characters before a space.
I'm not very good with Access VBA, so I'm trying to do this via a query.
my data is a list of SKUs, where I want to update the same field (sku) with a shorter SKU number, by using the Left$ function along with the InStr function to take all characters to the left of a space in the number.
test sku
E349CAJ6 OBROBRO
E357CAJ6 OBROSID
E329CAJ6 OWHIBRO
E358CAJ6 ONO SID
Note that the space isn't always in position 9, sometimes it varies. I was trying to use the following Query update value: Left$([IMPORT - EFF ORDERS]![SKU], InStr([IMPORT - EFF ORDERS]![SKU]," ",1))
The InStr, identifies the starting position based on the space, to use for the Left function.
The SKU field is a Short Text type field.
However, when I run the query, I get a "Type Conversion" error and none of the records will update.
I have wracked my brain to try to figure this one out and would appreciate an expert's fresh eyes on it.
Thank you so much in advance !
The ,1 is in wrong argument, really don't need it. If you want to use Compare argument then also use Start argument. Without explicit Start and Compare parameters, function will use defaults.
Left([IMPORT - EFF ORDERS]![SKU], InStr(1, [IMPORT - EFF ORDERS]![SKU], " ", 1))
InStr() in this case is returning a value that will be used as a length parameter, not a starting position. Start position for Left is first character.
This question already has an answer here:
What is going on with MySQL integer field matching string?
(1 answer)
Closed 2 years ago.
I have a table name workspaces with id has data type = bigint(20) unsigned
I'm trying to query my database as the following:
SELECT * FROM workspaces WHERE id = 1;
SELECT * FROM workspaces WHERE id = '1.a';
Both of them are returns the correct result. But I think the (2) statement is wrong, why sql still return correct value right? What is the reason?
Could you help me to understand why? Thank you so much.
Here is test case on db<>fiddle.
MySQL has complex casting rules for what happens when you try to compare a string literal (e.g. 1.a) against an integer column (id). What is happening here is that MySQL is taking the leading numbers from the string and then forming a number based on that. As a result, the check becomes 1 = 1, which is true for that particular record which is being returned.
On most other databases, your second query would not even execute, which is generally all the better for you. You should not mix numeric and non numeric types in the same comparison.
It extracts the number from string.
For example "1.a"=1
I hope it helps.
In a situation where the sides of a comparison operator (= in this case) don't match, the database will do its best to convert one side the other's type. If there's absolutely no way of doing it, it will throw an error, but it still won't be a syntax error (since the query itself has a valid form), but some error about type conversion.
MySQL, specifically, notoriously plays fast and loose with type conversions. In the case of converting a character literal to a numeric type, if the string starts with a digit, it will convert the starting sequence of digits to a number and ignore anything after it.
I'm using SSIS to separate good data from unusable date. In order to do that I used derived columns, script task and conditional split where I assigned certain conditions. One of the conditions I need to apply is that none of the numbers in one column cannot be negative. I'm guessing that the best way to solve this would be using conditional split, but I cannot get it to work. I'm new to SSIS, so any help would be appreciated.
You'd have an Expression like
[MyCaseSensitiveColumnName] < 0
and then name the output path something like BadData_NegativeValue
From the comments
that is what I did before, but I'm getting an error saying that The data types "DT_WSTR" and "DT_I4" are incompatible for binary operator ">"
That error message indicates that you are attempting to compare a unicode string (DT_WSTR) and an integer (DT_I4) and that the expression language does not allow it.
To resolve this type incompatibility, you would need to first convert the value of MyCaseSensitiveColumnName from DT_WSTR to an integer.
I'd likely add a Derived Column Component to my data flow and create a new column called MyCaseSensitiveColumnNameAsInteger with an expression like
(DT_I4) [MyCaseSensitiveColumnName]
Now, that may be perilous depending on the quality of your source data. I don't know why you are pulling numeric data in as a string. If there could be non whole numbers in the data set, then we will need to check before making the cast. If there are NULLs in that dataset, those too may cause issues.
That would result in our conditional split check becoming
[MyCaseSensitiveColumnNameAsInteger] < 0