I have simple (I thought) task to migrate table from db1 to db2 and stuck on this error which looks like about datetime. I completely lost: here is what I have:
Msg.
[9 LAB_IN [2]] Error: There was an error with 9 TABLE_OUT.Outputs[OLE DB Source Output].Columns[SCR_DATE] on 9 TABLE_OUT.Outputs[OLE DB Source Output]. The column status returned was: "Text was truncated or one or more characters had no match in the target code page.".
My source and target column ddl is same:
Column_name Type Computed Length
SCR_DATE datetime no 8
SCR_DATE datetime no 8
No null or garbage in source: this return nothing
SELECT TOP 10 SCR_DATE, LEN(SCR_DATE), *
FROM table_IN
WHERE LEN(SCR_DATE) <> 19 OR SCR_DATE IS nuLL
so it's page encoding?? this also looks same.
Source: SQL_Latin1_General_CP1_CI_AS
Target: SQL_Latin1_General_CP1_CI_AS
In my package I just have have ole-db source and destination
I'm on:
SELECT ##VERSION
Microsoft SQL Server 2012 - 11.0.5058.0 (X64)
What I'm missing here?
Thanks. Mario
P.S
THen after playing I got this error in derived column box:
Error at 9 Error at 9 Lab_IN [Derived Column [2]]: The function "SUBSTRING" does not support the data type "DT_DBTIMESTAMP" for parameter number 1. The type of the parameter could not be implicitly cast into a compatible type for the function. To perform this operation, the operand needs to be explicitly cast with a cast operator.
Related
I have cases where I want to a add or substract a variable number of days from a timestamp.
The most simple example is this:
SELECT CURRENT_TIMESTAMP - :MOD-DAY DAY
INTO :MYTIMESTAMP
FROM SYSIBM.SYSDUMMY1
My problem is figuring out the right cobol definition for MOD-DAY.
As far as I'm aware, we are running DB2 version 11.
According to https://www.ibm.com/support/knowledgecenter/SSEPEK_11.0.0/sqlref/src/tpc/db2z_datearithmetic.html
the DB2 definition of the variable must be DECIMAL(8,0)
That could be 9(08) or S9(08) but in both cases, and any other variation I have thought up so far, I get the compile error
DSNH312I E DSNHSMUD LINE 1181 COL 49 UNDEFINED OR UNUSABLE HOST VARIABLE "MOD-DAY"
I have of course made certain that MOD-DAY has been defined, so the key word must be UNUSABLE
The error code definition for DSNH312I is pretty generic:
https://www.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/msgs/src/tpc/dsnh312i.html
So does anyone know the right COBOL variable definition to use in this case?
Decimal in Mainframe-DB2 means comp-3.
So the field should be defined as S9(08) comp-3
If you look at the Cobol Copybooks generated by DB2 for DB2 Tables / Views you will see both the DB2 definition and the generated Cobol fields. That can be another way to solve queries like this
When I aggregate values in Google Data Studio with a date dimension on a PostgreSQL Connector, I see buggy behaviour. The symptom is that performing COUNT(DISTINCT) returns the same value as COUNT():
My theory is that it has something to do with the aggregation on the data occurring after the count has already happened. If I attempt the exact same aggregation on the same data in an exported CSV instead of directly from a PostgreSQL Connector Data Source, the issue does not reproduce:
My PostgreSQL Connector is connecting to Amazon Redshift (jdbc:postgresql://*******.eu-west-1.redshift.amazonaws.com) with the following custom query:
SELECT
userid,
submissionid,
date
FROM mytable
Workaround
If I stop using the default date field for the Date Dimension and aggregate my own dates directly in within the SQL query (date_byweek), the COUNT(DISTINCT) aggregation works as expected:
SELECT
userid,
submissionid,
to_char(date,'YYYY-IW') as date_byweek
FROM mytable
While this workaround solves my immediate problem, it sucks because I miss out on all the date functionality provided by Data Studio (Hierarchy Drill Down, Date Range filtering, etc.). Not to mention reducing my confidence at what else may be "buggy" within the product 😞
How to Reproduce
If you'd like to re-create the issue, using the following data as a PostgreSQL Data Source should suffice:
> SELECT * FROM mytable
userid submissionid
-------- -------------
1 1
2 2
1 3
1 4
3 5
> COUNT(DISTINCT userid) -- ERROR: Returns 5 when data source is PostgreSQL
> COUNT(DISTINCT userid) -- EXPECTED: Returns 3 when data source is CSV (exported from same PostgreSQL query above)
I'm happy to report that as of Sep 17 2020, there's a workaround.
DataStudio added the DATETIME_TRUNC function (see here https://support.google.com/datastudio/answer/9729685?), that allows you to add a custom field that truncs the original date to whatever granularity you want, without causing the distinct bug.
Attempting to set the display granularity in the report still causes the bug (i.e., you'll still set Oct 1 2020 12:00:00 instead of Oct 2020).
This can be solved by creating a SECOND custom field, which just returns the first, and then you can add IT to the report, change the display granularity, and everything will work OK.
I have the same issue with MySQL Connector. But my problem is solved, when I change date field format in DB from DATETIME (YYYY-MM-DD HH:MM:SS) to INT (Unixtimestamp). After connection this table to the Googe Datastudio I set type for this field as Date (YYYYMMDD) and all works, as expected. Hope, this may help you :)
In this Google forum there is a curious solution by Damien Choizit that involves combining your data source with itself. It works well for me.
https://support.google.com/datastudio/thread/13600719?hl=en&msgid=39060607
It says:
I figured out a solution in my case: I used a Blend Data joining twice the same data source with corresponding join key(s), then I specified a data range dimension only on the left side and selected the columns I wanted to CTD aggregate as "dimensions" (and not metric!) on the right side.
I looked though the forum but I couldn't find a issue like mine.
Essentially I have a table called [p005_MMAT].[dbo].[Storage_Max]. It has three columns Date, HistValue and Tag_ID. I want to make all the values in 'HistValue' column to have 2 decimal places. For example if a number is 1.1, I want it to be 1.10 or if its 1 then also I want it to look like 1.00.
Here is the sql update statement I am using
update [p005_MMAT].[dbo].[Storage_Max]
set [HistValue] = cast([HistValue] as decimal (10,2))
where [Tag_ID] = 94
After executing the query it says 3339 rows affected but when I perform a simple select statement it appears the column had no affect of. I have used that cast function in select statement and it adds two decimal places.
Please advice.
The problem is the datatype and SQL Server. Float or real will not have the trailing zeros. You either have to change the datatype of the column or just deal with it and handle the formatting in your queries or application.
You could run something like the following
select
cast([HistValue] as decimal (10,2))
from [p005_MMAT].[dbo].[Storage_Max]
where [Tag_ID] = 94
I was doing some tests on Postgres using the tinyint extension when I came across something surprising regarding its range. On typing select -128::tinyint it gave me an ERROR: tinyint out of range message which was not what I was expecting at all.
Assuming negative numbers should be 1 greater (or is it less) than the positive maximum (127 for single byte integers) I thought it was a bug with the extension, however on trying this with non-extended numbers I found exactly the same thing was happening.
select -32768::smallint -> out of range
select -2147483648::integer -> out of range
select -9223372036854775808::bigint -> out of range
Referring to the numeric data type documentation (https://www.postgresql.org/docs/current/datatype-numeric.html)
these numbers should all be possible - all negative numbers one less -32767, -2147483647, -9223372036854775807 work correctly so I am curious as to why this is happening, or does this even happen with other peoples copies.
I tried using both postgresql 10 and postgresql 11 on a ubuntu 16.x desktop.
I think this is because the cast operator :: has a higher precedence that the minus sign.
So -32768::smallint is executed as -1 * 32768::smallint which indeed is invalid.
Using parentheses fixes this: (-32768)::smallint or using the SQL standard cast() operator: cast(-32768 as smallint)
after several years of using Cognos, we are in process of testing conversion of Cognos Reports (8.3) to SSRS 2008 reports. we use Oracle database version 10g. in many of our reports we are converting we pass multiple values in parameters, however i cannot get this working in SSRS pointing to the Oracle datasource.
i have created parameter and set it to allow multiple values. these columns are integer types. the SQL filter is set as follows for example, where vendor_id IN (:Vendor_id). yet when I test the SQL, i get errors. i enter parameter values as comma-seperated for example, 102, 105, 107. errors as follows.
ORA-01722: invalid number
i've tried wrapping value in single, double quotes with same result. is there a different format to meet oracle syntax requirement? does multiple values only work for SQL server databases?
thanks in advance.
joe
As pointed out in this post, multi value parameters are concatenated and used as follows:
Select * from Table WHERE column1 in (:CommaSeparatedListOfValues)
http://consultingblogs.emc.com/stevewright/archive/2009/08/14/14763.aspx
So Vendor_id has to be Varchar2. I guess you have the data type of Vendor_id as integer?.