Environment:  Windows 7 with FileMaker Pro 14.

I have a test database that I am currently making changes to.  I saved the test database as a clone, so that I could test importing data back into it.  the Import functions allows me to import the first table of information just fine, but it will not let me import any other tables.   On any subsequent import, I can select the source table from my source file, but all of the target files are grayed out, except for the first file to which I was able to import into.  What am I doing wrong?  I will need to do this on a regular basis, as I will use this technique to move my changes into the live environment.

Thanks,

Linda

Edited January 10, 201610 yr by Linda L

"but all of the target files are grayed out..."

I assume you mean target tables. When setting up the import script you will need to be on a layout based on an occurrence of the target table.

By the way - did the concatenation problem get fixed? Most likely, a field size problem.

Edited January 10, 201610 yr by BruceR

Ahh, I see, I missed that nuance!  My book didn't mention anything about importing being associated with a layout.  I will give that a try.  In the future, what is the best way to handle working on a live database, ie making layout changes, table changes, etc?  I need to move my changes into the live database when the users are not in it.  I thought that making changes to a clone and then re-importing the live data made the most sense.  I don't have FileMaker Advanced.  does it facilitate development?

thanks,

Linda

12 hours ago, Linda L said:

My book didn't mention anything about importing being associated with a layout.

Pretty much everything in FM is associate with a layout.  It is the layout that determines what data table you are on... The  notion of "context".

For instance you can not do a "set field" into a regular field if you are not a layout based on the same table occurrence as the field name your using for the Set Field target.

 

 

FileMaker Advanced provides a variety of advantages, such as script debugging and ability to create and edit custom functions, ability to define custom menus, etc. For the issues you just discussed - no advantage.

I prefer mostly live development while users are off the system. Script and layout mods are OK for live development, database mods (relationships, field definitions) better done with users off the system.

What happened with the field size issue?

Thanks for your help and comments. Being on the correct layouts corrected my import problem.   

Bruce - I don't recall a field size issue.   I'll have to look back on my posts.  As you may have guessed, I'm learning as I go. My skills are a bit rusty!

Linda

That was a post about the concatenation calculation - and all the best guesses were that it was just the size of the field as displayed on the layout was too small.

Just tried that suggestion and it fixed the problem.  It was a merge field on the header.

thanks for that!  I forgot I had that problem.

Linda

On 01/10/2016 at 2:31 AM, BruceR said:

When setting up the import script you will need to be on a layout based on an occurrence of the target table.

 You need to be on a layout of the target table only when you are importing manually. If you are scripting the import, you can select any table as the target of the import, regardless of the current layout.