Hello Ann,
I can use generators in my case for this billing.Because i have
different types of billing and we are giving the provision for adding new
billtype also.Here the billtype means each is bill is identified by this
billtype id and have numbers.

eg:
billtype billname nextbillnumber

1 registration bill 000001
2 other charges 000001


At the time of creating the new billtype, the defaul next billnumber is
000001.(Character Field)

In billmaster table , both this billtype and billnumbers are primary key
and the billnumber is 0203/000001.
here 0203 is the financial year and it is concatenated with the next
billnumber.
Whenever i press save, i will take this next billnumber and update the
nextbillnumber to the next value.

in my crete new bill number procedure

FINYEAR='0203';
SELECT NEXTBILLNUMBER FROM BILLTYPES WHERE BILLTYPE = :BILLTYPE INTO
:NEXTBILL;
IF ((CAST(:NEXTBILL AS INTEGER) + 1) < 100000) THEN
UPDATE BILLTYPES SET NEXTBILLNUMBER = lpad((CAST(:NEXTBILL AS INTEGER)
+ 1),'0',6)
WHERE BILLTYPE = :BILLTYPE;
ELSE
UPDATE BILLTYPES SET NEXTBILLNUMBER = CAST(:NEXTBILL AS INTEGER) + 1
WHERE BILLTYPE = :BILLTYPE;
NEXTBILL = FINYEAR||'/'||NEXTBILL;
BILLNUMBER = NEXTBILL;

and in the main procedure i am calling this procedure for creating the new
billnumber

and the return value i am using for converting the temp billnumber to the
original bill number
As i told earlier, first i save the temp number in the billmaster table
and billdetails table .
because if the items are entered in the bill., the stock should be reduced
from the stockmaster.

this is the procedure for converting the temp number to the original number

insert into billmaster (billnumber,billtype,billamount) values
(:NEWbillnumber,:billtype,:billamount);
update billdetails set billnumber=:newbillnumber and billtype=:billtype
where billnumber=:tempbillnumber and
billtype=:billtype;
delete from billmaster where billnumber=:tempbillnumber and billtype=:billtype;


Sivaraman
At 03:03 PM 08/01/2003 -0500, you wrote:

>At 09:39 AM 1/5/2003 -0500, pschmidt@... wrote:
>
> >There are really three methods, all are acceptable by may have pros and
> cons.
> >
> >First is to store the number somewhere else
>
>Right.
>
>
> >Second, use a queue, if a record is rolled back, then the number is stored
> >in a
> >queue, and inserts always get numbers from the queue
>
>That has the secondary problem that if the rollback is not done under
>program control (power or network failure, for example) numbers are
>lost.
>
>
> >Third, the delayed number, in this case you delay inserting the number,
> >until the
> >very last point, for example in an after insert trigger.
>
>Changing the "new" value in an after insert trigger has no effect
>since the record is already stored.
>
>The best solution in my opinion, is to use a generator. Depending
>on the load, I'd probably get the number and immediately store an
>empty record with a status of some sort indicating that this is a
>work in progress. After that is committed, I'd update the record
>to the desired state and commit that. You won't be able to use "not
>null" fields, of course, and you'll still need to run a program from
>time to time to find any numbers that were lost between the creation
>of the generated value and storing the dummy record.
>
>When using paper forms, there's always some way to indicate that
>a particular form was voided - people never having been infallible.
>
>
>
>Regards,
>
>Ann
>www.ibphoenix.com
>We have answers.
>
>
>
>To unsubscribe from this group, send an email to:
>ib-support-unsubscribe@egroups.com
>
>
>
>Your use of Yahoo! Groups is subject to the
><http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.