I’m a somewhat intermediate/newbie developer and am about to try make a design change after having put a lot of data into an older working design.
Better planning probably could have helped me dodge this sort of problem, but I imagine this sort of thing happens even to seasoned developers as projects sometimes change, good reason or no. So hopefully someone can give me some advice.
I’m building an app, and have several separate forms for recording financial transactions. But after using the system this way for a while, I realized I was foolish in making each transaction form specific and want to reduce these various forms to only 3 specifying the type of transaction inside each of the forms.
I know I can write agents to push data of certain types into new forms, and all that, but am concerned about having fields of the same name. I also dread arbitrarily renaming every field name while I go through the conversion & updating process. I had thought of sharing all the fields which I want to keep the same between forms, but I feel in the back of my mind like there’s a deep chasm I might be prancing about the edge of as I tinker with all this.
Am I on the right track? Are there serious pitfalls to my intended approach? Is there a time-tested way to approach these types of problems or resources that explain the best way(s)?
I’m not sure that I totally understand your design but I would be inclined to create a single form that would Include one or more computed SubForms based on the values entered. There are some problems with this approach because the subform formula is only computed on Open, but there are ways around this. I have posted a method to close and reopen the UIDoc elsewhere in this forum (or the 4-5 one can’t remember which) So what I would do is have a form that contains the Tombstone data that would be needed to evaluate which SubForm/s to open the trigger the UIDoc close and re-Open, then the appropriate SubForm/s will display have the user fill them in and submit the document. In most cases they will hardly see the brief flash as the UIDoc closes and then re-opens.
I think I understand what you are attempting to do, and my first reaction is to wonder why you are worrying about fields with the same name between forms.
I can only assume that the reason you feel you can migrate to a single, one-size-fits-all form that allows you to just flag each document for the transaction type is because there ARE fields of the same name.
Next, I find myself curious about exactly what your thoughts were that brought you to the conclusion that it was"foolish" to build the design into its current state.
Another thing, from your post, I want to make sure you are not confusing “form” and “document”. It sounded like you were calling those one and the same. They are different. You have a bunch of documents in the database, that for all intents and purposes (not counting responses) are peers, just that they might have different items on them. Depending on your transaction type, you have told your design to use a specific form to display the data that is held in the documents. You could build another form altogether, and still display the current documents, but then that all depends on the specifics of your case.
Let me/us know more, and maybe this discussion might lead you to where you ultimately should be.
Subject: RE: Merging Forms whilst skirting disaster
My apologies for mixing up my words.
I’m trying to redesign the forms so that the field and semantic structures make more sense, but I have to go through the documents in some fashion, probably by using agents, so that the document data points towards the ‘new’ form, or otherwise reflect my modifications to the current form (i.e. documents which use form ‘x’ now use form ‘y’, but contains field ‘a’ whose value is set to ‘y’, that value ‘y’ now being the same as the name of form y).
Hopefully that helps my issues make more sense instead of less.
Subject: RE: Merging Forms whilst skirting disaster
Samuel,
If you go into any view in your DB, you sill see somthing called “Form Formula” in the design Pane. You can specify the form to open the docs with for a view specifically.
Inversely, you can set a Form filed on the DB documents to specify which form they should open with. This can be set via an agent to say:
If doc.Form(0) = “formA” then
doc.Form = “FormB”
End If
You could also use that agent with a different requirement, say a field on a document.
Subject: RE: Merging Forms whilst skirting disaster
Shawn, this is great. Just what I was looking for. I’m still a bit nervous about the field migration. Should I just copy and paste the relevant fields to the new form and then use your agents to update the active forms? Could I also use that type of agent to populate say, a date field which is a shared field for use in all forms, where it’s contents would be made of several separate date fields across several forms?
Incidentally, that’s where the foolishness comes in.
Thanks everyone for your responses. I feel like I’m beginning to cobble together a plan of action now.
Subject: RE: Merging Forms whilst skirting disaster
Sam,
There seems to be several things whirling around inside your plan.
(At least from what I can tell)
First you have the question,
You wrote:
“What form should I use to display my data?”
Which is really the issue addressed by the snippets in my previous post. They should help you to set a form on a doc or use a view to display existing documents in a totally redesigned form.
If you are trying to create a form that ‘combines’ other parts of your data then, Bill gives you a great suggestion in the subforms direction. It allows you to create subforms that capture the ‘important’ data from your existing documents and display that data on a consolidated form. This means that you don’t have to struggle with the data field concatenation in this question.
You wrote:
“Could I also use that type of agent to populate say, a date field which is a shared field for use in all forms, where it’s contents would be made of several separate date fields across several forms?”
Or in any other data manipulation you perform just to show what already exists.
