Crash TOL when used functions of construción of series by SQL

[rcsoto]

When used DBSeries, DBSeriesTable or DBSeriesColumn obtain the next result:

Warning: (Funcion DBSeries) y1999m01d02 is not a date of dating Mensual at
register 2

Warning: (Funcion DBSeries) y1999m01d03 is not a date of dating Mensual at
register 3

then, TOL crash.

The sentences used in the example are:

Real DBOpen("_alias_odbc","_user_","_pwd_");

Text strSql =
"

select cast('1999/01/01' as datetime) as valueDate, 586516820.895 as value

union

select cast('1999/02/01' as datetime), 525347193.128 union
select cast('1999/03/01' as datetime), 587432210.614

";

Set ser = DBSeries(strSql, Mensual, SetOfText("value"), Empty, ?);

Real DBClose("_alias_odbc_");

These functions can be proven with any SQL, that the result is always same....
crash TOL.

[rcsoto]

In the exposed example, the casting made to the dates is not correct, because the
dates are return in format "yyyy/dd/mm", and TOL waits for the
format "yyyy/mm/dd".

Casting correct for the example is:

convert(datetime, '1999/01/01', 121)

With this simple modification, obtains to clear the error messages that showed to
us previously.

The new example is:

Real DBOpen("_alias_odbc_","","");

Text strSql =
"

select convert(datetime, '1999/01/01', 121) as valueDate, 586516820.895 as

value union

select convert(datetime, '1999/02/01', 121), 525347193.128 union
select convert(datetime, '1999/03/01', 121), 587432210.614

";

Set tabla = DBTable(strSql);
Set ser = DBSeries(strSql, Mensual, SetOfText("value"), Empty, ?);

Real DBClose("_alias_odbc_");

[danirus]

Please, to send bug reports try to be very concise. This SQL sentence is so
complicated to be debugged. If the error is on DBSeries functions, the SQL
sentence must be as simple as possible.
Bug reassigned to Manuel Balderrábano, Tol-Project SQL Interface developer.

[manuelb]

The error comes from a tricky use of dating in BTimeSerie class:

dating was sometimes given as NULL to be filled-out later on and, therefore, a
check if it had been given was neccessary before incrementing it.

Anyway, this is a behaviour that should have never been this way, will change it in
the future.