How to create autoincrement both Parent Child New Record when Save

[KC Chin]

Hi Bruce,

Tried for a week, still confuse.

Is there an example of Parent-Child where no autoincrement occurred when user Insert New Parent and Insert New Child records?  Only autoincrement(both parent & child) after user Save the record.

I went thru' all the examples, still can't figure which one.

Parent Table, pt:pk_pt_sysid(auto)

pt:pt_sysid (long)

Child Table, ct:pk_ct_sysid(auto) and ct:fk_pt_sysid(non auto and link to pt:pk_pt_sysid)

ct:ct_sysid (long)

pt:pt_sysid (long)

Parent(Browse) > FormBrowse (Parent-Form, Child Browse) >Form(Child)

[Bruce]

Hi KC,

What version of NetTalk?
What version of Clarion?
What backend are you using?

Do you want the auto-increment to happen late, or early?

Cheers
Bruce

[KC Chin]

Bruce,
I am using NetTalk 4.31 pre-release 33, C63 9058 ABC, and XP PRO as backend.

As for the autoincrement, must be late.
Example:
Insert New Record for Parent
Parent - Insert New record and
Child - Insert few new record
then Save

Change Record For Parent and Child
Parent - change
Child - Insert additional record to the existing records
then Save

[Bruce]

Hi KC,

Sorry by "backend" I meant SQL or TPS?

Why do you want your auto-increment to be late? If you are adding children at the same time as adding the parent, then the parent but auto-inc early so that the children get the correct link value.

Or am I missing something?

Cheers
Bruce

[KC Chin]

Backend = TPS

I need to auto increment to be late because
1.  those user tend to press "Back Button" and "Forward Button" on IE/FF.
2.  those use tend to "close" IE/FF and those records they added remain in the children's table.

I think I will use queue for the children so that it won't be writing to the table until the user save.

Any example of Parent-Children, using queue then save to database?

Thank you for the reply.

[Bruce]

Hi KC,

You can't use a Queue, because the server is heavily multi-threaded and queues are not thread-safe.
Use a temporary table instead - using the memory driver if you have it.

However I think you might be approaching this from slightly the wrong direction.
Personally what I do is add a field to the parent file. Called "InsertComplete". This is set to 1 only
when the user hits the Save button (ie in the ValdateInsert routine). Records which are not
InsertComplete are removed by a background process after a period of time.

Alternatively, make a temp table for the Parent, and a temp for the child, and then copy the
records to the main table after the user clicks on Save. The main disadvantage with this approach
is that the user does not know the "reference number" for what he is adding. eg if he's adding
an Invoice then there is no "Invoice Number".

Cheers
Bruce

[KC Chin]

I will stick to your advice on temp table for parent & child file.
As for the "Invoice No", it is not critical. I will generate and inform the user after the whole temp table is saved.  The "Invoice No" will autogenerate (not sysid) for the user.   This way, only internal hidden sysid, which is primary key for relationship (parent * children) is maintain.

As for the temp table, it will be dynamic create according to user id.  These will prevent other user from creating same table.

Cheers and have a good day.
Chin

[Bruce]

I don't recommend creating the table according to user. That'll result in a lot of tidy-up being necessary.

Rather make a memory table, and add the SessionID as a filter on the table. ie multiple users can share the same table -
it's fast and thread safe - and easy to purge if necessary.

Cheers
Bruce

[KC Chin]

Hi Bruce,
"Rather make a memory table..." I believe you are referring to In-Memory Driver which I don't have.

Thank you for the tips of "adding SessionID as filter on the table."  This is the one I never thought off.

Cheers and good day to you.
Chin

[Bruce]

Yes, the In-Memory driver.
Highly recommended, I find it very useful in all my apps.
Makes it very easy to "switch" between files in ram and files on disk.

Put it on your wish list, and as soon as you have the funds I definitely recommend getting it. It makes a BIG difference to both the coding and long-term handling of temporary tables.

If you don't get it though, make the temp table a table not a Queue. Queues are not thread-safe, and NetTalk generates a lot of threads, so using Queues in this environment is a bad idea.

Cheers
Bruce