https://bz.apache.org/ooo/show_bug.cgi?id=109652
--- Comment #22 from D Denny <mis...@daviddenny.co.uk> ---
(In reply to mroe from comment #21)
> (In reply to D Denny from comment #20)
> > I have run separately your sample sub and proven to myself that
> > CDateFromISO() runs perfectly happily on its own.
>
Firstly, thanks very much for your comprehensive help and careful attention!
Gratefully received.
> The simply question is:
> Which string you get from
> columnFinalBudget = RowSet.getString(16)
> for dates > 2021-09-30?
>
YYYY-MM-DD : example 2021-10-05
> If the column is defined as DATE you should better read the date rather the
> string representation. So your macro will be independent from any
> uncontrolled string conversion.
please see below **
>
> AND: Please test your macro with
> Option Explicit
> and define your variables to get sure that there is not an unwanted
> conversion!
> Dim columnFinalBudget As String
Applied
**
changed .getString to getDate as
dim columnFinalBudget as date ' string
columnFinalBudget
= RowSet.getDate(16) ' String(16)
print columnFinalBudget
resulting in
"Incorrect Property Value"
I think that because the date returned from the SQL VIEW is YYYY-MM-DD
it will be necessary to convert it another way, by string removing the "-"
separators.
Or, I could change the VIEW result definition. Currently specified as DATE.
So it appears (also re your comment below) that, while SQL is writing dates in
the format YYYY-MM-DD, Basic is expecting the format YYYYMMDD.
Maybe I should be trying getXXX first. I'll have a look at that.
[... Work In Progress, BRB ...]
>
>
> For the original reported bug I suggest to change the help for
> »CDateFromISO«, that it awaits a String in the form of "YYYYMMDD". This is
> what the counter part »CDateToISO« supplies.
--
You are receiving this mail because:
You are the assignee for the issue.
You are on the CC list for the issue.
