"Best Way" Navigation

[RPCia]

Current Setup: FMS 5.5 FMP 6—70% Flat File

Migrating to: FMS 7 FMP 7 & 8 mixed

I have started and restarted this project at least 10 times over the last month. The system has to be able to handle all aspects of our company, from quoting, order entry, creating job tickets for each line item on an order, then once the order moves out of entry phase. Each of the departments will access the jobs in a different way.

Department 1: Quoting

Department 2: Order Entry

Department 3: Preproduction

Department 4: Production

Department 5: Shipping

Department 6: Invoicing/Accounting

I believe my attempts to follow the anchor~buoy method lead me astray when it comes to using an interface table, because all the data entry layouts should be based on the nav/interface layout. OK, so I start all my anchors with a TO of the nav/interface table, but the original nav/interface TO has 2 or 3 relationships to other nav tables depending on the method used to putll the tab names and access criteria.

Would it be common practice to duplicate the entire TOG hang it off the side of each and everyone of my anchor TOG? Or is it ok to use the GTRR and “hop/teleport” to the initial Nav/interface TO run my nav script?

I guess biggest problem I am having is coming up with the “best” way to handle the user navigation and integrate it with my data. With fmp8 is it still common to use globals as the data entry, I would like to think not and move to more of a transaction model but without using globals how can I lock the system down and know when an item has been edited.

My Goals:

1) Use one underlying TO so that I do not have to constantly change my portals, and nav fields on my layouts

2) Implement a Tabbed interface that is table driven and permission based to display the tabs and names.

3) Tabbed interface must be able to allow sub tabs.

4) Template Layout should have little changes required, meaning once the user interface is set up I am trying to avoid having to switch between tog’s

This is by no means all my issues but I am trying to get some feedback on what has been holding up my development.

I have done research on this site, FMAdvisor, FileMaker Magazine, and the FileMaker Whitepapers. Often reading through the theories and best practices makes sense but I usually come to a point in my development where I say well where do I go from here. I often wish to bounce ideas off someone else and have no one to turn to hence I end up turning back to research on the web, and usually discover a different method that seems like it will work out better. And I end up starting over.

That being said if there is anyone that lives in IOWA and wishes to form an fmPug group let me know.

The company I work for has never had an IT staff/Database Developer before me. I am the first person who has ever touched the database and had any training on schooling on relational database theories. After a year of working with the current system, making improvements to business rules and structure we have finally hit a point where I have said enough is enough we need to develop a new system. For one our current FMS 5.5 is maxed out at around 120 files, and secondly some of the improvements I am being asked to make can only be done, at least in my opinion, in a relational databases. This would put us over the 125 file limit. Explaining this to people with no database experience is hard enough but to my boss everything is a simple as adding a field or two (ie flat file). My frustration level is starting to reach its max, if I can just come up with a navigation system I could put together a demo of how it would improve things.

Sorry this got so long, some of it is probably just venting!

[Ender]

Greetings RCPia,

It sounds like you've got a pretty complex project ahead of you. It's good that you're taking steps to plan for it.

In my opinion, the modular approach is best for a large, complex solution like this. Combining files into modules based on how much interaction the tables have with each other reduces the number of files somewhat, but doesn't put all your eggs in one basket.

Now for your questions:

OK, so I start all my anchors with a TO of the nav/interface table, but the original nav/interface TO has 2 or 3 relationships to other nav tables depending on the method used to putll the tab names and access criteria.

It's not clear to me what the "nav/interface table" is. If you're using an Interface file (using the separation model), there's no need to have a separate table for the Interface, as you would normally base the layout and fields on the actual tables from the data files. Perhaps you can clarify this if I've interpreted something wrong.

Would it be common practice to duplicate the entire TOG hang it off the side of each and everyone of my anchor TOG? Or is it ok to use the GTRR and “hop/teleport” to the initial Nav/interface TO run my nav script?

I'm not a big fan of the anchor-bouy model because of this extra complexity. Personally, I like to link all the related tables into one TOG for each file. But maybe an 'anchor-bouy' advocate can chime in about how navigation is best handled between TOGs in the same file.

I guess biggest problem I am having is coming up with the “best” way to handle the user navigation and integrate it with my data. With fmp8 is it still common to use globals as the data entry, I would like to think not and move to more of a transaction model but without using globals how can I lock the system down and know when an item has been edited.

I like to keep things simple, using the actual fields most of the time. While I have seen a couple tightly controlled solutions with globals for all data-entry, I don't think it's as common as you think. Anyway, there are various techniques for ensuring proper data-entry and protecting the integrity of that data. It all kind of depends on what's needed.

My Goals:

1) Use one underlying TO so that I do not have to constantly change my portals, and nav fields on my layouts

2) Implement a Tabbed interface that is table driven and permission based to display the tabs and names.

3) Tabbed interface must be able to allow sub tabs.

4) Template Layout should have little changes required, meaning once the user interface is set up I am trying to avoid having to switch between tog’s

I have seen something like this shown off at DevCon. I'll have to dig through my conference materials to see if I can figure out what it was.

[Ender]

This is the interface model I was thinking of:

http://solutions.filemaker.com/solutions/search_details.jsp?serial=2214

[RPCia]

Ender,

Thanks for your replies I will take a look at the demo file as soon as I get a chance.

In response to your first post.

It seems like you understand what I was trying to say, all the demos I have found always base the layouts on the Nav TO but maybe I misread something along the way and got tunnel vision on this matter.

Question: How do you ensure data integrity on entry, the two solutions I have implemented in the past either makes use of globals or field validation.

The use of globals for entry seems to work but is a lot of overhead at this point. The second method using field validation can cause a tremendous amount of unwanted popup dialogs. Especially if the user accidentally clicks out of a field and commits the record before they are ready to. Or if they start to enter an order then get a phone call and need to get out of the current record/layout and look something up for the person on the phone.

If you are allowing them to work with the actual data then how do you ensure accurate data entry?

While I do like the fact that serials can be created on commit I do not like the way FMP still auto commits a record. This could cause all the field validation dialogs to display when they are not wanted. The “Save record changes automatically” in my opinion is not enough, it is simply another dialog that will delay data entry.

What I really would like to see is a similar feature that forgoes the dialog and just does not commit the record until the user commits it through a button or script provided by the developer.

[RPCia]

Ender,

I am not sure if it was by design or by accident but the nav button scripts do not function.

PatternCount( v_list; v_script & "¶") ≥ 1; ( Get ( FileName ); v_script );

IsEmpty(v_label); "";

( Get ( FileName ); "[uTL] Under Construction")

)

There is a custom function with the solution but it requires 3 parameters and these function calls are only passing 2.

Specifically I was trying to use the new button to see how they handle a new record but it does not work. I will take a look at it to try to fill in the gaps.

Thanks for any time and help you may proide.

[Ender]

If you are allowing them to work with the actual data then how do you ensure accurate data entry?

Well, I use a combination of calculated flags to indicate when a section is complete, and scripts to set a Status field for the record indicating what stage in the process it's in.

In general, I like to allow the record to be exited with partial data, then allow the user to return later to finish. The Status field then indicates the progress of the data entry.

What I really would like to see is a similar feature that forgoes the dialog and just does not commit the record until the user commits it through a button or script provided by the developer.

It sounds like the set of globals might be the way to go then.

I am not sure if it was by design or by accident but the nav button scripts do not function.

PatternCount( v_list; v_script & "¶") ≥ 1; ( Get ( FileName ); v_script );

IsEmpty(v_label); "";

( Get ( FileName ); "[uTL] Under Construction")

)

It looks like this might be referring to some event script plugin, but you could contact the author to be sure. Or since it's a script process anyway, you can probably rewrite the script to handle the 'F' parameter instead of having the calc do it.

[Tim W]

Hi,

I agree with ender about the record status flag idea. I have a similar solution to what you describe. On the sales order entries, I allow an incomplete record to be exited. A verification script is executed upon every way possible to exit the record, which sets the flag as incomplete. An incomplete record cannot be approved. So it must be correctly completed before the sale can be billed.

My solution is in ver.5.5 and I am now working to bring it to ver. 8. One thing I did that I have mixed feelings about is I made the line item file a combination file (serving quotes, sales orders, and purchase requisitions). Under this idea, a single record could support lines in each of the above uses with unique keys attaching to each. Sounds great, in real life things don't always work out like you planned.

Example: User wants to use a different desc in SO from what we called it in Quotes, and in purchase requisitions we need to buy 3 parts to make the item listed in the S O.

I have considered different desc fields for each use but I still have to deal with the purchase requisitions issue above.

Tackle each function separately in modular fashion, with a consistant way of doing things (look/feel, logic, etc.)

What I plan to do is this.

1. Group tables logically into files by module

2. Maintain line item tables separately

3. Convert and test one module at a time connecting it to the previous ones.

However, I am always open to any better ideas.

Hope this helps,

Tim

[Razumovsky]

Under this idea, a single record could support lines in each of the above uses with unique keys attaching to each. Sounds great, in real life things don't always work out like you planned.

You should be able to eat your cake as well if you create a join table that connects serving quotes, sales orders, and purchase requisitions to display them in a single portal from distinct tables.

Migration is another matter. Your general approach sounds solid, but there are plenty of known issues that need to be considered. I trust you have read the appropriate methodology papers on the subject and poked around in that area of the forum.

-Raz