We use AQ heavily here.  In testing using the SETDATE command to move the
date into next year, we found that the TODAY variable in AQ seems to give
incorrect values.  Has anyone else checked this out, perhaps with Hourglass
or one of the other more sophisticated date-moving systems?

We did obtain the source code from the Interex contributed library but
haven't had time to do anything with it.  It appears to be a very large
monolithic SPL program.
        Don Inghram, Systems Mgr.
        The Christian & Missionary Alliance
        Colorado Springs, CO  (719) 265-2154
        [log in to unmask]


> -----Original Message-----
> From: Bob Walker [SMTP:[log in to unmask]]
> Sent: Monday, October 25, 1999 5:47 AM
> To:   [log in to unmask]
> Subject:      Re: AQ/3000
>
> We still use AQ  as well.
> (AQ/3000 is the old Advanced Query 3000 still found in the
> contributed library)
> We are trying to wean ourselves to Query for ad hoc online queries
> but AQ has a number of nice features Query still doesn't have, and
> it's a great report writer. One problem, we just starting using reals
> in our databases and AQ doesn't handle them.
>
> And, as far as we're concerned, AQ3000 IS Y2K COMPLIANT.
>
> What makes you think it isn't?
>
> AQ's internal date format(D1 item, same space as an I1) is good 'till
> Dec 31, 2029(1=01/01/1930). (Adager knows of this item type and
> does conversions on it).  This, of course, is only a concern if you
> use the internal AQ date format.  We've moved away from D1 items and
> use character fields for dates.
>
> 3k does have the source code for AQ3000, but I don't think their too
> involved in it. We got the source code  fom Chris Bartram and our SPL
> guy looked through it with the idea of adding real number support,
> but we didn't get too far. He characterized the source code as
> Byzantine.
>
> Bob.
>
>