pop up lists, & repeating fields w/n portal

[synergyx]

Hello everyone here's my dilema

The db in question is basically a flat file setup

The group only wants to add a particular feature. I'm not sure if it is possible.

The end result is to be able to select a file from the portal and create a new record with most but not all of the fields automatically !

1. When they do a search on the form view layout the request is this; to have a portal that will display the found set of records...(simple enough)

2.a couple of the fields required are pop up lists...(here I run into the problem that these 2 fields w/n the portal's list of records the data on them is that of the record being viewed and not the file(s) being shown in the portal.

3.Another gremlin is that in the status area of Filemaker it shows the number of items found during a search, however the portal is not showing all of them. I suspect the repeating fields within each record is somehow interfeing with it. Any idea's are greatly appreciated.

4. do I use a calculation to carry over data to be entered in to a new record. As I only want to select most but not all of the fields. or is it as simple as using the Getfield calc

5. Lastly this db has over 3000 records and needless to say,it needs alot of massaging. what is the best way to preserve the data from the repeating fields and is building a inv_line items the best and next thing to do without getting into a complete rewrite?!?!

[CobaltSky]

Your use of terminology makes it a little difficult to piece your problem together.

A 'flat file' is one with only a single table (ie no portals or relationships), but after saying the db is flat, you then refer to portals and related files.

A find is designed to locate records in the current file, and a portal is designed to locate records in another (related) file. Records returned from a 'find' (you seem to be calling it a 'search') correspond to criteria entered while in "Find Mode". Conversly, records displayed in a portal are dependent on a match between two key fields as defined in the relationship that the portal is based on.

One would therefore not normally expect (or want or need) to view the results of a 'find' in a portal. Find results can be viewed by using a 'View as List' layout, or by paging through the records one at a time on a 'View as Form' layout.

You then talk about wanting to be able to "select a file from the portal". However portals can display selected records from a file - not whole files or multiple files (unless you mean a list of file names which are stored in a field of a related database??). That aside, if the inetntion is to duplicate a selected record in the related database, this could be achieved using a script attached to a button in the portal which uses the following two commands

Go to related Record [ ]

Duplicate Record/Request.

---

When you say 'create a new record with most but not all of the fields automatically !' I assume you mean that you want to duplicate some values. If this is what you mean, your script could either duplicate the entire record and then selectively delete some values, or create a new record and then selectively add some values.

To carry over data into a new record, it is generally desirable to set appropriate 'Auto enter' options for each of the fields (eg auto enter from previous, auto-enter by calculation, auto enter default value etc).

In order to display data from a related file, fields within a portal must be chosen (when 'building' the portal in layout mode) by first selecting the relevant portal relationship (from the drop-down menu at the top of the "Specify Field..." dialog listing). If fields from the current file are placed in a portal, they will display data from the current file.

In relation to your last question, it is not possible to offer any meaningful advice about alternative db structures without having a clear picture of your current database structure. However it sounds as though you currently have repeating fields and relationships/portals mixed together. Broadly speaking, repeating fields are a legacy from the time before relationships and portals were introduced into FileMaker Pro. Repeating fields were used to add limited flexibility to flat db setups. When used in relational dbs they more frequently cause a reduction in flexibility, if not an outright conflict in design logic.

It may well be desirable to migrate to a fully relational structure, however any way you approach it that is likely to be a sizeable job. However it would be risky to offer specific advice about how to go about it without knowing a lot more about what is there at present and what you ultimately need to achieve.