Import NOT importing value lists....

[ron G]

I wrote an import script that works great... except it will not bring in the value list from the source table?

There are two versions of the same application: 741 and 886. (Different content)

I open 741 and change the 'editable value list'.

I run the import script from 886 using 741 as a source and everything seems right. Except, the value list of 741 arent' brought over. Yes, I am able to bring all fields from 741 into 886 but that doesn't seem to make a difference.

So, the question is: "How do I import a value list???"

Thanks

[dansmith65]

"How do I import a value list???"

You don't! It's a manually copy/paste kinda thing.

You could submit it as a feature request: http://www.filemaker.com/company/contact/feature_request.html

[ron G]

You don't! It's a manually copy/paste kinda thing.

You could submit it as a feature request: http://www.filemaker...re_request.html

Wow! Isn't there a 'work around' for this? (Besides burdening the user with 'retyping' the value list).

Not bringing in the 'value list' will inevitably result in users 'retyping' the list, making spelling mistakes, (think 'financ' instead of 'finance') which will screw up reports and result in members belonging to both the 'finance' and 'financ' committees. As a developer I must now write special code to GTRR from the report module so that the 'misspelled' word can be corrected.

I am extremely surprised that FM in version 11 hasn't addressed this! This means that versions 1 through 11 also do not import value lists. Am I the only one who finds this a problem????

[Mark Hardee]

Wow! Isn't there a 'work around' for this?

I am extremely surprised that FM in version 11 hasn't addressed this! This means that versions 1 through 11 also do not import value lists. Am I the only one who finds this a problem?

Generally construct value lists from field values.. That way you are only display unique values.. So, yes, you are the only one! :-)

[dansmith65]

Wow! Isn't there a 'work around' for this?

Just thought of a work-around...

Use a script to get ValueListItems from your old file, then in your new file, insert these values in a new table and construct the value list from the table. Then build an interface for the user to be able to add/remove records from the table in order to modify the value list.

[ron G]

Dan,

Your idea of using a 'script to get value list items' sounds interesting. But incorporating 'Open Manage Value Lists' opens ALL my value lists (there are around 25) which requiress the unsophisticated user to a) select the right VL and change the contents appropriately. I don't have much faith in users to do this 100% so I am looking for script commands to do it without user involvement.

To that end it seems that FM should do it as part of import. But, apparently not.

So, the question is "What do application developers do to get a user's previous version List Value into a newer version? "Tell them to go back into the 'old' version, write down the value list and (without error) re-enter it into the new one? Hard to believe this is THE solution?

[dansmith65]

Have a look at the ValueListItems function: it will get your value list items without opening the Manage Value Lists window.

[ron G]

I am convinced that the best way to do this is to use a separate table. Thanks for your help.... ron

[bcooney]

I stand vindicated! I always warn people about custom value lists. Use a table! (and store IDs, not text values).

[ron G]

I stand vindicated! I always warn people about custom value lists. Use a table! (and store IDs, not text values).

Interesting. Are you saying to setup the source table to show ID as the first field and 'Description' as the second along with 'show only 2nd field? What kind of problems are caused by just storing the 'text values'?

[dansmith65]

What kind of problems are caused by just storing the 'text values'?

What if you want to re-name a value? If you've stored text value only, there could be numerous places to change the name, with ID/text, there is one place.

[ron G]

Here is another 'weird' FM 11 anomalie.

I have a table called AWARDS:

It consists of: Name, .... etc... AWARD

I have a 2nd table called AWARDSpopup:

It consists of the PKawardID and AWARDname

I relate the 2 tables via AwardName and AWARD. Make the AWARDS::Award field a popup and specify that the information is be from AWARDSpopup. It shows and everything works ok. (It is just a list of awards).

Here is the weird part. I write an import script that DELETES the contents of AWARDSpopup and then IMPORTS the contents of the same table into AWARDSpopup from a previous version. It did not work? It keeps importing the previous table (AWARDS)

When I print out the script it shows for AWARDSpopup "Target: Awards", Method: Add, etc.

Yet, when I look at the specified script on screen, I have specified:

GOTO Layout [Awards POPUP] (Awards POPUP)] As you can see, the layout is based on Awards PopUp NOT AWARDS.

Question: "Where does FM get the instruction to put the imported records other than where I have specified via the layout?"

Thanks

[ron G]

Got it!

All I needed to do was to highlight the Import Records - [Add; ----] script step and specify the table by checking the SPECIFY INPUT ORDER and specifying the table. (Before running the script... afterwords there is no ability to designate the target table)

Seems counter intuitive to me but now I know. Hope this may help some other lost soul... :laugh2:

[bcooney]

Why isn't the relationship between Awards and AwardsPop by AwardID? Basically, your Awards table is a join table btw Members and AwardsPopup, right? The names of the tables threw me a bit. I would have named them MemAwards and Awards. And yes, I would create a value list of AwardID Desc, showing just the second field for use in populating the join table.