No Fields are Defined in the Data Source?

[LaRetta]

This is a first. Maybe I'm beyond tired and just don't see it.

I exported some records (FM7, WinXP) as .fp7. I can open that file directly and the fields display fine and all records are displayed. But when I try to import that set into another file, I get the FM error sited in the subject.

I am on the correct table (layout Activities). I get the error even before I can attempt field mapping - as soon as I select the file. But the fields are in that file - along with the records! Do I need a very long vacation or is something going on? I posted on a few forums, sorry. I know the weekends are a bit slow and I need to resolve this before I attempt any more import/exports. It has worked in the past just fine but now 3 files will not import. I even rebooted my system and restarted FM to no avail. Help!!

Is there a reasonable explanation or do I need to reinstall Developer or am I simply blind to something simple?

LaRetta

[LaRetta]

Update - Additional export/imports have worked but the three files still will not import. And this morning, it's doing it again! I need to depend upon this process. I am splitting data across tables and FM will not allow importing from one table to another so only export then import will work for me.

I don't have this problem exporting as text - I guess I'll have to stick with that method. I have never seen FM unable to open its own fp7's before. Especially when they open directly. I have not messed with the field names or anything; they are very simple exports, layout switch to another table then import. But if I don't figure it out, it might bite me later when I least expect it. I guess I'll need to contact FM if there are no ideas. Reinstall of Developer didn't help. I can find no references to this error code either. Well, thanks anyway everyone.

LaRetta

[ecrates]

I was having the same problem... was it with a file w. only one table and no relationships that you could not import from?

Apparently all that you have to do is create one TO of the table and link them together with any field.

then you can import the file into another fm7 file...

this must be a minor bug.... but there may be a reason for it..

we'll see

best

ee

[LaRetta]

Thanks for the idea ... I'll certainly try a join. Actually what I ended up doing is creating an external file just for this export/import process. Pulling into this file works perfectly. This Data Source problem is so inconsistent, ie, scripted export, no field changes or export-type changes whatsoever. No renaming files or folders - no activity between export and import. When it occurs however, it's always on creating a new fp7 only; pulls are fine. A bug? Well, an OS/FM anomaly for sure ... one I now watch out for.

FM's data-handling abilities are so rock-solid that this kind of inconsistent behavior can leave one with their (pants) guard down (no backups). It actually helped me tighten my data defenses a bit.

LaRetta

[Ender]

Others have reported a bug with importing between hosted databases. Is this your situation LaRetta?

[LaRetta]

The problem has happened (from two different clients) while hosting, Mike, but has also occurred just as frequently on my stand-alone system - both Developer 7 and FMP7 with WinXP. Any theory of an OS pattern was just debunked by ecrates' report of the same behavior. Out of an estimated 150 export/imports over the last three months, it has happened 9 times. Not a lot, but enough to cause me to give up the practice for now. Besides, pulling is the same theory in reverse; except I'm using a file in which FM recognizes the data source.

I have never received this error with any other export type or FM version and I've even exited FM entirely after export, tested the new fp7 (which opens nicely), checked the text fields for validity, re-opened FM and imported and it has done it - no import dialog - just an error message. And NO FM file has been able to import them. Exporting from these files works fine - they just can't be imported back into FM.

Bad sector? But the file appears normal in all other discernible ways. It feels like a critical piece of FM index (or reserved space) didn't write correctly to the new file although the export was normal and successful in appearance. Well, that's my sense of it anyway. But there is more in heaven and earth than what I know (or sense) ...

LaRetta

[Computer Geek]

I had a similar problem where FM would not recognize that there was records or fields in a database. I never figured out why, but I exported the fields that I wanted to import to another fm database. I then imported them into my solution. It had no problem with importing from that database.

[Paulr81755]

I have had the same inconsistent problm. What is the currently available workaround? Thanks

[LaRetta]

I guess workarounds as we've discussed, might be to pull (import into an existing FM7 file) or exporting as anything other than FM7 -- or just be aware of it. You will know whether the import wasn't successful because the error stops it cold. It might be a drag if it was part of a major nightly unattended process and it didn't complete because of it. I like using an FM7 file so I pull then pull back into the main file ... works very well.