It's not neccesary to put this in a separate table, just set a field in the table storing the jobs, but don't display it on the layouts for users to see. You can set the field to Auto-Enter a serial number and it will take care of the incrementing for you automatically.
OK I just noticed you are wanting this to be based on jobs coming from 2 different tables, not sure what the purpose is in that, but if this is neccesary, I would recommend a job table in addition to Table A or B, and actually work from the Job Table, create a new record there (where the job number is set through auto-enter as I said) Then push it to the related record in Table A or Table B. not knowing the function of Table A or Table B, I can't say for sure, but I would recommend working completely from layouts based in the Job Table and working with Table A and B through the relationship so that any new record would give you what you need, otherwise if you are in Table A and they create a new Record, you are going to have to force it to go back to the Job Table and create your Job record, which can be scripted, but you have to be careful not to let users create new records from the menu or keyboard commands without running the script as well.
That is a good idea...
How does one "push" a field to a related record?
I have three tables pertenant to this discussion; JobNumbers, ServiceCalls and SalesCalls.
Both ServiceCalls and SalesCalls need job numbers which can never be the same, as all jobs are costed through one JobCosting table. All Labor and materials go to the appropriate job number.
If you base your layout on jobs and display the fields from the other table through the relationship, when you fill in the fields it will automatically create the related record and "push" the job ID for you.
You may also want to validate that if there is a related record in "table A" there cannot be one in "table B" unless that is a valid option.
Digital Carpentry LLC
"Let us build a foundation for your business."
I really like the concept; I could have a tab representing SalesCall entry and another tab representing ServiceCall entry.
Should I build a portal to make those entries while in the "jobs" table/layout?
Yes, and put common information in the Jobs field (anyfield you would need for both) you can show those things at the top and then do tabs below for the more specific fields, you probably won't have to use a portal (a portal is for displaying multiple fields from another database) just display the fields within the tab. This will give a seamless UI that works like a flat file, but the structure in the background will have the separate tables to break down the information.