Stan after Stan after Jerry: >> As you know, no version of IMAGE offers a 'date' >> native data type. >Make that "No HP 3000 version of IMAGE". I seem >to recall IMAGE/1000 had data type(s), *years* ago! >I've been agitating for slew of date data types, to correspond >with the date types supported by the new Date intrinsics! >er, make that: IMAGE/1000 had date data type(s). Just for reference, at the SIGIMAGE meeting at IPROF-97 last spring we had an extended discussion on the subject of DATE data type(s) in Image/SQL... And we were all over the map (some people suggested we ran *way* off the edge of *any* map); did not reach consensus or anything close to it. Then at HP World - Chicago I believe we had 100 percent agreement among the people in the room (or at least very close to it) that if there was going to be just one Image/SQL DATE data type, it should conform to the SQL date / time standard. Having just one Image/SQL DATE data type goes along with the idea that because there are so many valid, semi-valid, and totally screwy date conventions out there, trying to handle all or even most of them with a large variety of data types within Image/SQL itself would be a large effort; doing just one would be significantly easier. Of course that would leave users to do their own conversions in to and out of that one data type. If HP was going to implement more than one DATE data type directly in IMAGE, best idea I've seen so far (just my personal opinion) is still the one Stan proposed at IPROF-97: DATE(nn) , which would allow for 00-99 = 100 different DATE (or maybe even other types) of data types. Once the DATE(nn) convention was established, then it would hopefully be relatively easy to add new variations as needs and requirements changed.... With the incredible diversity of data that people loosely refer to as "date" information, I sometimes wonder if DATE(nn) would be enough; it might have to go to DATE(nnn) !!... In any case, per the HP "State of the Product" at SIGIMAGE - Chicago, after getting several major new enhancements out to the user community (B-trees, bundled 32-bit ODBC, Master Dataset Dynamic Expansion (MDX), multiple PUT-DELETE semaphores, and QUERY B-tree support) the next set of features that HP will be focusing on will include "mitigation" of the 4 MB Transaction Manager limit and additional scalability enhancements. Also keep in mind that with the recent formal commitment by CSY to 64-bit MPE, I believe it is reasonable to assume that the HP R&D Database Lab will have a significant number of issues to attend to in that area (but note that far as I know HP has made no specific comments on that; either on or off the record). So delivery of any kind of Image/SQL internal DATE data type does not appear to be on the short-term horizon. If and when it gets implemented will probably depend on a variety of factors: Where it shows up on the SIGIMAGE '98 Enhancement Ballot, discussions at IPROF-98, and whether or not user-financed enhancements become a reality in one form or another.... In other words, stay tuned.... Ken Sletten SIGIMAGE Chair