Re: Re: CAST() no longer working with OOO 330m16

  Ocke,

It has certainly nothing to sea with the SQL version or server type. I 
work in a company envoriment, everyone uses the same SQL server, same 
native OO-connector. Everyone works on OO 3.2 without problems, i test 
3.3 and have the CAST problem:
cast(`mag_news_export`.`DATUM` as date) AS `DATUM`  where 
`mag_news_export`.`DATUM` has a imported data (dd/mm/yyyy)
hope it helps

Fernand
> Moin,
>
> I just have to set the issue to wontfix. :-(
> The problem seems to be the database. Even with odbctest I get the 
> same results => error and I tested a StarOffice 9.2 which is equal to 
> OOo 3.2, same error as in OOo 3.2.1 and 3.3.
>
> Did anyone did an upgrade to a newer MySQL version before the 
> statement stop working?
>
> - oj
>
> On 08.12.2010 19:04, Fernand Vanrie wrote:
>> Alex ,
>>
>> As always, we gave good reasons to use a technique, so let hope the CAST
>> problem will be fixed soon =-)
>>> Fernand,
>>>
>>> Well I also use EXTRACT(), but have found that I still have to CAST
>>> the type. If I just use the DATE/TIME functions on their own, the
>>> results are inconsistent across the months, especially when adding or
>>> subtracting. I haven't kept any of my old queries that did direct
>>> application of date addition / substraction because they were of no
>>> use to me, so I rewrote them all with CAST and EXTRACT.
>>>
>>> An example of a current one that works is given below :
>>>
>>> SELECT CAST(EXTRACT(YEAR FROM CURDATE()) as SIGNED)-CAST(EXTRACT(YEAR
>>> FROM Date1) as SIGNED)+1 as 'Renewal Num' FROM mybase where
>>> MONTH(Date1) = 12
>>>
>>> I do not consider this to be an optimised way of obtaining the result
>>> I wanted, but I found it to be the only way that worked reliably for
>>> each month of the year, independently of the date provided by
>>> CURRENT_DATE. In a more simplified expression, the results were wrong
>>> by +/- 1 dependent on the MONTH given and the date provided by
>>> CURRENT_DATE.
>>>
>>> It may be that the underlying cause to this is a problem with date
>>> handling by Mysql, and not OOo at all, but I haven't checked this out.
>>>
>>>
>>>
>>> Alex
>>>
>>>
>>>
>>> ----- "Fernand Vanrie"<[email protected]> a écrit :
>>>
>>>> Alex ,
>>>>
>>>> its also a fact that there are (better) alternatives for cast Date()
>>>>
>>>> convert() or even left() and right()
>>>>> Hi Fernand,
>>>>>
>>>>> Done, but whether it will make any difference ? Its not a blocker
>>>> because it doesn't cause a crash, or lose your data, but it is surely
>>>> a regression from 3.2.
>>>>>
>>>>> Alex
>>>>>
>>>>>
>>>>>
>>>>> ----- "Fernand Vanrie"<[email protected]> a écrit :
>>>>>
>>>>>> Alexander ,
>>>>>>
>>>>>> It sould be good to send this message also to
>>>> [email protected]
>>>>>> there they decide over live and dead :-)
>>>>>>
>>>>>> greetz
>>>>>>
>>>>>> Fernand
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Le 08/12/10 13:38, Reizinger Zoltán a écrit :
>>>>>>>> Hi Fernand,
>>>>>>>> It feels to me as I touched in some days ago, and find it, as a
>>>>>> known
>>>>>>>> issue with cast in MySQL:
>>>>>>>> http://qa.openoffice.org/issues/show_bug.cgi?id=115436
>>>>>>>> Zoltan
>>>>>>>>
>>>>>>> Hmm, this would not be good for me if this is the case because I
>>>> use
>>>>>> a
>>>>>>> lot of cast statements with date values in mysql. The reason is
>>>>>> simple,
>>>>>>> default typing of the values in date strings used to lead to
>>>> funny
>>>>>>> behaviour for me on OOo, which meant that calculations I had in
>>>> my
>>>>>>> queries based on the default types led to incorrect results. I
>>>> was
>>>>>> thus
>>>>>>> forced into using CAST to ensure correct handling. If that
>>>>>> functionality
>>>>>>> has now gone away with the latest dev release, whereas it works
>>>> in
>>>>>> 3.2,
>>>>>>> and connector 1.0.0, I see no incentive to move to 3.3.
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>
>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>> For additional commands, e-mail: [email protected]
>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]