When you open the import dialog, you will see at top on left (Source) and on right (Target).
To import, you must be on a layout based upon your target table. If you truly want to import records from same table, you must export those records first and then import the exported file. If that doesn't help, please describe more of your situation and we'll help you through it. :smileyhappy:
i think that is the problem that the layout is listed as "Go to layout" as the first step - i clicked on the layout that's needed but that doesn't show on the source or target when i specifiy order from the Import Records - The layout is called "column report" and i'd like to take the field with the word "drop" and move to another layout for all "drop" records - When i did this with the tech yesterday, the "drop test" and "drop test 2" came up on the drop down for Layouts (within the file) - I can't seem to figure out how to add a layout to the list of layouts where i would export these records. I remember "todd, the tech guy" having difficulty with this too and we had to go to manage databases, and relationships and add another "table"
This is confusing but i feel i'm so close but missing something!! Did i provide you with enough info?
With versions greater than 6, it is important to recognize that layouts belong to table occurrences. And table occurrences are different representations of the same table. You must import while standing on a layout based upon target.
You say the layout is called ‘Column report.’ But I need to know the table occurrence name that the layout is based upon. To find out, go to the Column Report layout and drop into layout mode. Then select from top menu, Layouts > Layout Setup. What does it say in the ‘Show Records from’ pop-up? That is your table occurrence name.
It sounds like you then need to find records (source) with the word “drop” in a field and copy those records to another table (target)? Can you explain why? What does this data represent and what are you trying to accomplish by moving the records?
it's 10am in NY - i'm running to a mtg now and won't be back until about 1:30 pm.. I'll be back in touch then so that we can hope to finish and resolve this (wish i had more time now!))
thank you so much! Barb
sorry for the confusion with two threads - i'm staying with this post from now on
I want to respond to the layout called "column report" - the table occurrence name that the layout is based upon is "2009-2010" - that's what is listed in the "show Records" from the layout setup.
My database is used for work we do in school districts (hence 2009-2010) - we have records (of students) that can be "dropped" from the current database as the students have moved, or for many other reasons can be dropped from our current (2009-2010) database. WE have a new file (or database) for each school year. In the past, we typically delete such records. I would now like to "cut and paste" - as a matter of speaking - those records that could be dropped into it's own table (file? layout? ) so we can refer to it and we can add to it say once monthly.
I tried the new Table option (as the target) in the import records box but still got the error message "table cannot be imported into itself" I think that i somehow need to create a layout to go to?? It was so much easier with the technician yesterday because we had one layout (Drop Test) which after much thought on his part, we somehow came up with the "Drop Test 2" - an additional layout for moving records from the Source to the Target.
thank you once again, Barb Heim
What the tech was doing was importing and creating a new table simultaneously (as I indicated). If you pop that Target pop-up during the import, you will see at the bottom that FM will provide a duplicate table name with a '2' at the end, which is example what you ended up with with your Drop Test and Drop Test 2. But now, if Drop Test 2 was in your relational graph, it would show Drop Test 2 2 (if exporting from Drop Test 2) or Drop Test 3 (if exporting from Drop Test). It will import the found set into a new layout based upon the new table. Anyway, I really believe that it isn't the way to go because you will then be creating new files or tables and having to duplicate then change your script every year, having to create new tables and so forth.
I realize you don't want to do the standard of 'creating a Students table and relating StudentID to an Enrollments table StudentID etc. But all years' enrollments should be in ONE table, designated with field called SchoolYrStart in which (for current table) you would put 2009. Having each school year as a file really limits you. For instance, if Child Services wants to know what school years Jimmy Smith attended, you will have to open (and search) every single 'school year file' that you have and then manually write down the results. Then you will have to go to the dropped file(s) and search there as well. Whereas, if all school years are kept together, you can find 'Jimmy Smith' and produce a report of every school year he attended with simple indication of his Status (Current, Completed or Dropped).
And if all school years are in one table, it is easy to move dropped students to a 'dropped' table. You would then only have two places to ever look for student. I will be more than happy to produce a simple demo file once I know whether you would consider 1) keeping your Enrollments in one table (regardless of school year) and 2) keeping dropped students within the table as well and just using a Status field to omit dropped when you need 'active' reports or whether you still want to move the dropped students to a dropped table.
This might sound complex but it actually would make your life very easy!
At the end of each school year (June), we then start a Summer file (for students who attend the 6 week summer program) and then we start the new school year file. We have many many files of school years! I would love to stop this process, your explanation sounds inviting. I'm sure we woudl be able to generate reports (i.e. school district lists, school placements, therapist...)??? on FM 10 there is a demo of a Student Record - is this typical to what you're referring to?
hi again - i haven't heard from you in a few days, just wondering if you're working up a demo of what you were explaining to me about comibining school years.
thanks for your help, Barb
Hi Barb, I'm sorry ... I missed this. I would be happy to come up with a simple demo but I would need a bit more information. I don't know what tables (or files) are involved, what field names nor what data. Do you have a Students table with unique StudentID which contains the student information? Are the fields the same in every enrollment table? How do you designate summer school or class?
If you would provide me with a bit more then I would be happy to put together a structural demo and even a sample of how to merge the enrollment data. :smileyhappy:
UPDATE: Oh, and I would need to know whether you would consider leaving 'dropped' students within the same table or whether you truly need them moved. If left in same table, it is easy to omit the 'dropped' whenever you want an active list but you wouldn't be the first to want dropped (or deleted) records archived off into another table/file. Leaving all records in same table would be the safest.
I am in Filemaker 15 and am importing from one file to another. (Two separate files...). The tables are named the same.
I receive the "A Table cannot be imported into itself" error. It appears that Filemaker does not take note that they are in different files, only that the tables are named the same!
I changed the name of the source table. It still doesn't work! I am receiving the same error!
I think not. Importing from a recovered file into a clone of an undamaged copy is a standard procedure for recovering data when file corruption occurs. In such cases, every table in the clone and ever table in the recovered copy are exactly the same and no problems are encountered importing the data from one to the other.
If this were not the case, Report an Issue would be swamped with reports of developers who are unable to to do this.
I suggest taking a closer look at your table occurrence names and what data source tables they represent. Could it be that your target table occurrence has an external data source reference to the same data source table as your source table occurrence?
When I changed the name of the source table in the other file it updated accordingly in the Import dialog. In other words, the external data source is correct and using the correct table from the other file.
I also deleted and rebuilt the Import script step to no avail...
I ran the following tests in FileMaker 15 Advanced:
I took a small file with a table named "child" and saved a clone of it.
I opened the clone and imported records from Child in the original file into Child of the clone with no problems
I then created a brand new file and named it's table "Child".
I was also able to import into this table from the original file with no problems.
I understand that but the problem remains...
I have also recovered both files and there is no damage.