Tony,

>But I first want to mention that some of your tutorial screens in the current help file don't match your new 2.3 version, so I wasn't sure of some of my coding.

Yes, we're hot and heavy on this right now...we snuck in some new features in the version of 2.3 that is on our web site and we are updating the Jump Starts accordingly.

>It would also be helpful to perhaps keep the results of the generator output, because every time I wanted to do over one of the 'Business Object Settings' setups I had to re-enter all the defaults and display names again. My tables contain a lot of fields and I had to do them over again a few times to try and get the defaults I wanted set correctly. It would have saved tons of time if this was kept. Perhaps you have another suggestion here.

This is a new feature that's coming soon. We plan to save the settings in a Domain-Specific Language (DSL) model file which can be re-read by the Business Layer Generator at a later date. You will eventually be able to change the DSL model file and generate database scripts, data access classes, etc. from the model...some very groovy stuff <s>.

>I noticed also that when I set up the bindings for my controls, that the Binding source is case sensitive.

>For instance, on my controls I had set the BindingSource to PurHead. I wasn't able to get any binding at all. When I changed it to Purhead, with a lower case 'h', the bindings worked. The 'PurHead' spelling was in all my old code so I had to go through hundreds of controls to correct this. I had to open the 'Binding Source Selection' window to get the correct spelling into the code, too, just changing the spelling didn't seem to work.
>
>Can you tell me if this is supposed to be case sensitive or not?

Are you using FoxPro data or SQL Server data? FoxPro tends to be case sensitive.

>And finally, the other problem I'm having is driving me nuts again. I have a table, Pur_head, that contains my purchasing requistion headers. It has a unique Id of ReqId.

>I have two other tables, Pur_item and Pur_recv, that contain line items and receivers. Pur_item has it's own unique key, ItemId, and an indexed ReqId field. Pur_recv has it's own unique key, ReceiverId, and an indexed ReqId field.
>
>When I use your code to create a new Item record, the code somehow creates a new row, with a new ItemId number, but also changes the ReqId number on the first record in the table. For example:
>
>The original ItemId 1, ReqId 49990, now is ItemId 1, ReqId 56098, and there is a new record: ItemId 34056, ReqId 56098.
>
>Why is the code changing the ReqId of the first record in the table? Any clues?

I'm having a hard time grasping the scenario...You mention both the Pur_item and Pur_Recv tables--which table is the problem occurring in? Do you have two tables used in a single business object. If so, have you created a relationship between the two tables. If you are using multiple tables each in their own business object have you established relationships between the two business objects?

Best Regards,