>> Joe, although you seem to have a good grasp of time and its nuances,
<<

Lord, no! That guy is Rick Snodgrass. his book on temproal queries in
SQL is on-line at his website at the University of AZ. I can simply
recognize the most common basic problems in DDL by sight now; I make a
part of my living fixing databases that look like what you posted.

>> I am not sure if you tried to solve my problem or found it easier
(i.e.less time) to solve your own. <<

I published this kind of solution in SQL FOR SMARTIES, SQL PUZZLES and
several magazine columns years ago when I was still thinking of time as
points and not durations. How else would I know that there would have
to be an elaborate and error-prone self-join in whatever kludge got
posted?

Your problem *is* the design and that is the root of the difficulty in
even this simple query. It will get orders of magntiude worse. The
elaborate self-joins eat up time exponentially with DB size. A single
missing row throws reports off. Gaps are hard to detect.

I know; I have been paid to fix it before at a research company working
with a bank to look for patterns in checking account and credit card
balances. Hiring me for a month is expensive

>> Ps: you were right about the DDL. I should have posted one. Sorry and
will do better next time. <<

Nada. The number of frequent posters who have been asked over and over
and still will not post DDL is remarkable. Then of course there are the
guys who push a button and dump code in a format that only a machine
could love ..

--CELKO--
Please post DDL, so that people do not have to guess what the keys,
constraints, Declarative Referential Integrity, datatypes, etc. in your
schema are. Sample data is also a good idea, along with clear
specifications.


*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!