Hi all,
Strange one this time
Got two environments - one is 10.2.1 which is fine and the other is a new 10.2.2.
Both on separate servers and both pointing to two separate database servers (the latter being SQL 2014).
I have confirmed the table structures in both database servers to be identical as is the data.
And the process of migration has simply been a full content store deployment from one to another.
Problem is, while 70% of the reports work, there are about 30% of reports (fairly large number) that do not work due to data items failing to validate/work.
Mainly date related such as :
The operation "less_equal" is invalid for the following combination of data types: "varchar" and "date2
Now while I can probably fix them, I don't understand why these are popping up.
I was expecting no engine change or functionality change of existing functions/data types yet clearly this is not the case.
I even tried a copy to clipboard and back out into the new one but same issue.
Finally, I reverting the data source connection to point to the 10.2.1 database and again, same issue.
It's almost like 10.2.1 is fine with the data items yet 10.2.1 is not.
Any advice would be appreciated!
Thanks!
Was the report specification upgrade done?
Certainly was
Also re-tried without upgrading and leaving as is
And finally tried as is + the manual upgrade job
All 3 with same issue.
I'll output the SQL tomorrow once back in the office for both environments and see if there is a difference but something has clearly changed in the way it handles dates
Point both 10.2.1 and 10.2.2 to the same DB (the original DB) and see what happens. If it works then it is not Cognos, something with your 2nd instance of DB.
You are converting dates that are stored as strings to date datatype?
I have found that while date stored as string in format YYYYMMDD used to convert fine in C1021 using
cast([date as string] as date)
in C1022 the string parameter to cast function must be in format YYYY-MM-DD to work.
cognostechie: the "Finally, I reverting the data source connection to point to the 10.2.1 database and again, same issue." was exactly that but no go there either.
I think prikala might have hit the nail on the head
Somewhat annoying though so I'll dig further into it but in our case, the source system is extremely old and file based so I think 10.2.2 has now just given me a whole load of ETL work to do to fix the dates for the reporting source
Ok. I did not know that there were cast functions in the report/model.