Thanks for your advice, Tim.

Regards,
Primoz

> Yes - we have a (unique) shift number for each 12 - hour period and for
> each gasoline station. So we just run Stored Procedures or Queries for
> shift numbers. Makes it much easier ... :-)
>
> If I may give some advice - if you are doing accounting data,
> then instead
> of using dates (which I have always found to be a real pain, not
> because of
> SQL, but because dates are not logical), assign each order to an
> "accounting period". So, for example, if month 1 (in your
> financial (i.e.,
> accounting period) terms) runs from 22 December to 21 January,
> you just do
> a search or group by or sum or whatever on the accounting period.
> You don't
> have to worry exactly when this month starts and that month ends/
>
> What you do is have a table of accounting periods, that define the start
> date and end date of each accounting period. That means that the
> client can
> define his own accounting periods - in real terms, this takes care of the
> clients having different month - ends and month - starts. Then when you
> store the data, you also store the accounting period. It makes the online
> transaction processing and accounting stuff MUCH more simple ...
>
> HTH
>
> Tim
>
>
>
> >Basically just because of hidding old orders from user.
> >So you suggest, that I should keep ALL orders in one table and omit
> >accessable one with select statement e.g.
> >select * from orders where OrderDate < some_date ?
> >
> >Regards,
> >Primoz
>
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>