Example of card form with editable fields from mult tables?

dkuznetsov

Hi there,

I am just starting with NAV customizations and have a question on best way to extend the long table. The customization I am working on requires new fields for the table with record length of 4000 so I cannot add the new fields into that table. I have to create an "extension" table with additional fields and the key matching the original table's key. The base table's triggers handle the creation / update of the extension table records. The new fields just need to be added to the existing maintenance form i.e. user should not know that the data is coming from another table.

Is there an example of card form that has editable fields from multiple table that I could use as a template?

Thanks,
Dmitriy Kuznetsov

David_Singleton

dkuznetsov wrote:

The customization I am working on requires new fields for the table with record length of 4000 so I cannot add the new fields into that table.

Dmitriy I think if you need more than 4,000 then the issue is bad database design. better is to fix the design.

dkuznetsov

David, I agree with your design comment. Unfortunately the table I am adding a new field to is part of the partner solution and re-engineering it is not an option for me. So now I am looking for a "standard" way to add a field from another table to an existing card form for that monster table, and have it maintained as if it were a single table from the user's perspective. I hope there are existing forms out there that have editable fields from multiple tables on single form.

Thanks,
Dmitriy

DenSter

I'm not going to get involved with whether the design is good or bad, I'll just give you an option of how you can do this. What you are looking for is a subform. Say you have the new table, linked to the Item table, with some sort of text records in them, so you have a bunch of text lines for each item. First you create a list form for the text items. Then you add a subform to the Item Card, which points to your new list form, with the link between the Item table and the new table based on the Item. The subform on the Item Card will look just like it was meant to be there.

I agree with David by the way, I'm not convinced that you're on the right track desin-wise, but to make that determination I'd have to be closely involved in your project. Good luck with your form

dkuznetsov

Thanks Daniel. The subform seems to be a good approach. The only difference is that it's going to be a card subform in my case.

Regarding the design approach, I thought about it but could not find a good solution so if you guys could give me an advice on other options I would greatly appreciate it. I am customizing the vertical line of business app that rides on top of NAV. There is a table in there (part of that package) that represents a certain entity from that app. As part of customization, for each instance (record) of that entity the application must capture some additional data elements. So naturally my first reaction was to add new fields to that table and form. Unfortunately the table is 4000 characters long so I cannot add a new field, not a single one. So I created another table that is an "extension" of the original table, and maintain one-to-one relationship between the two within the primary table's triggers. Then I will add the new fields to the original form (will try the subform approach) so that both tables could be maintained on the same form.

Thanks,
Dmitriy

DenSter

dkuznetsov wrote:

Thanks Daniel. The subform seems to be a good approach. The only difference is that it's going to be a card subform in my case.

Sure that'll work. I don't like making it look like attributes of an entity belong to another entity, it can only result in confusion, but technically it is quite easy to accomplish. Last year I was involved in a project where the customer had a 1-to-1 link between customer and contact, and they wanted some of the customer fields to show in a subform on the contact card. I did not agree with this design either, but it really does look like the customer fields are part of the contact, seemless integration.

dkuznetsov wrote:

Regarding the design approach..... <snipsnip>

4000 characters sounds more like you would put that into a Word document, which I would probably store in a network folder and provide access through document links. If it's straight text I would consider using waldo's navpad (search the download section)

MissesMagic

Subform is a good way,
but remember one thing!

especially if you want to let the user edit the subform, keep in mind that the user can change the record he is in!
So take care that always the correct (and only) record of the table is shown.

If I understand right, you have only ONE additional record...


If you just have a few fields, consider of using form-variables displaying and editing the values.

dkuznetsov

Thanks for your help. The subform approach saved me some time as I already had a form for the extension table. Another (perhaps silly) question regarding form mods in form designer. What is the best way to delete the tab and all fields on that tab from the form? I tried to update Tab Control properties and it works fine when I remove the last tab but gets all confused when the tab in the middle of the group gets deleted - the fields from the tab being deleted and the tabs coming after it get all lumped together on the previous tabs.

Dmitriy

Savatage

For example I have 5 Tabs.
Tab 3 has no fields.

First I move all the field from tab 4 to 3
Second I move all the fields from tab 5 to tab 4.
Now I remove the tab field name of tab 3 & it's done.

Note: the tab removed is always the last one so you can't just "PULL OUT" a tab.

DenSter

You don't even have to move any fields. Remove the tab name, but leave the commas in place.

So say your tabcontrol has the following pages: "General,Invoicing,Replenishment", and you want to remove the Invoicing tab. First you remove all the fields from the tab, and then you change the Pages property to "General,,Replenishment", note how the commas are still all there. No need to move the fields from the Replenishment tab first.

Savatage

Really! That was the way I knew forever. It's been so long since I removed tabs I never learned another way. \:D/

DenSter

This was posted maybe a month or so ago, and I never knew it worked that way either 8)