Move text file import specification from one database to another

[Isaac]

I have some carefully curated text file import specifications, such as I would refer to in an argument of TransferText, in one database.

I need to move them to another database. Is this possible to do successfully......

I tried clicking the Options button in the External Data import wizard, where you can then check "Import/Export Specs". It seemed I had to import at least one actual item, so I imported a Table, and I kept Import/Export Specs checked.

I got this message "The search key was not found in any record". And, by running the TransferText a minute later, indeed--the import specification is not found (was not imported apparently).

Researched a little and found this sad thread that lead nowhere - any one here have insight into this pesky problem?

This is one area I've found is a weakness of my ability to fluidly and easily replicate functionality in databases....those import specs. I guess I need to start fully documenting them, because I can't seem to rely on Access to really preserve them - or have I missed something here that will help me

 

[theDBguy]

Hi. Interesting, I don't remember failing to export/import a spec through that method.

 

[isladogs]

Was this an old style IMEX specification as stored in the two MSysIMEX... system tables OR a new style IMEX Data task which is stored as XML?
If unsure of the difference, please see View & Edit IMEX Data Tasks - Mendip Data Systems. Its also available here (1) View & Edit IMEX Data Task Specifications | Access World Forums (access-programmers.co.uk)

 

[Isaac]

I'm almost 100% certain it'd be the newer one. the original ones were created in the latest 2019 office 365

PS. I feel I ought to mention at this point - I went ahead and re-created it, so the urgency of my post is lessened. Still, I'll be glad of anything I learn from it.

 

[isladogs]

Please check whether there were related records in the MSysIMEx system tables. That's unlikely if you used the wizard for creating the import / export but not impossible depending on the file type created.

 

[Pat Hartman]

I know you can import the old file specs. I've done it.

Personally, I never use the new one. It is not simpler. It just obfuscates the details. Colin has spent a lot of effort to create a database that lets you modify them. Perhaps you can make use of some of that code to copy them from one database to another.

 

[isladogs]

It also works with the new style XML data tasks when the Import/Export Specs option is ticked - I've just checked...
BUT of course you do need to also transfer the relevant table(s) as well or there will be nothing shown in the wizard

 

[Pat Hartman]

That's interesting. Can you create these system tables? If you can't, just create a new spec in the new database and Access will create the tables. Then you can import the spec.

If this actually fixes the problem, please report it to Microsoft as a bug because the act of importing should automatically create the necessary system tables. There is a Feedback link when you go to Files. It is just above the options item. MS does read these. Doesn't mean the bug gets fixed but they do try.

 

[isladogs]

Sorry Pat but I'm not sure who you're responding to.
Using the new style data tasks the system tables aren't (normally) created so aren't transferred or re-created either.
What I'm saying is the new style XML is transferred as well as the tables concerned when that option is ticked ... providing the details match
BUT having said that, if there is a disparity between the XML contents and the tables transferred, the wizard entry will be missing.

 

[Pat Hartman]

BUT of course you do need to also transfer the relevant table(s) as well or there will be nothing shown in the wizard

I thought you were talking about the MSys tables. Are you referring to the tables used by the spec?

 

[isladogs]

If you export Table1 for which the wizard was used to create an XML data task, it will also export the XML.
However if you export a different table but don't export Table1, the XML won't be exported.

Yes you can force Access to create the two MSysIMEX tables. Use the undocumented command SysCmd(555)

 

[Isaac]

Okay, I think my mistake was not realizing that I had to import the relevant table - the one associated with the import spec, the destination of the data itself - along with selecting the import specs. I didn't realize this because this is the first time I've tried to import "JUST" the import specs (having forgotten to 'include' it the first time with a mass import I did).

Problem solved - Thank you for pointing me in the right direction.