Import Specification

[BD]

I have a import specification saved in the database with a Primary Key
but after I imported the text file the table hasn't any Primary key.
Why this is suppose to happen, what I'm doing wrong?

[]'s
BD

 

[Ken Snell \(MVP\)]

Tell us more details about the specification's contents, what the actual
import step is that you use (with all arguments), are you importing to an
existing table or to a new table, etc.

 

[BD]

It's a big specification's contents with about 230 fields and only one
field is indexed that the PK I want. After import the table beyond not
having the PK it make an index of another field that I wasn't selected
to be an index. This is very cumbersome. The step I use is coma
delimited fields, "" for text qualifier and has fields names. I'm
import to a new table. I use the following code to execute it:

DoCmd.TransferText acImportDelim, "tblNameImportSpec", "tblName",
"C:\Temp\tblName.ASC", True

Tell us more details about the specification's contents, what the actual
import step is that you use (with all arguments), are you importing to an
existing table or to a new table, etc.

[]'s
BD

 

[Ken Snell \(MVP\)]

Not sure why you don't get the desired result, but what I suggest you do is
to import the data to an empty table, then use an append query to copy the
data to a permanent table whose fields are indexed the way you want.

--

Ken Snell
<MS ACCESS MVP>

It's a big specification's contents with about 230 fields and only one
field is indexed that the PK I want. After import the table beyond not
having the PK it make an index of another field that I wasn't selected
to be an index. This is very cumbersome. The step I use is coma
delimited fields, "" for text qualifier and has fields names. I'm
import to a new table. I use the following code to execute it:

DoCmd.TransferText acImportDelim, "tblNameImportSpec", "tblName",
"C:\Temp\tblName.ASC", True

Tell us more details about the specification's contents, what the actual
import step is that you use (with all arguments), are you importing to an
existing table or to a new table, etc.

[]'s
BD

 

[BD]

Not sure why you don't get the desired result, but what I suggest you do is
to import the data to an empty table, then use an append query to copy the
data to a permanent table whose fields are indexed the way you want.

That is what I going to do but in such a way with the Access 97 as
with the Access 2003 the same problem occur. If I terminate the import
through the menu/external data the table is build successfully. Is
there any reason and explication for that happen?
[]'s
BD

 

[Ken Snell \(MVP\)]

If your question is, why does the same thing happen with 97 and 2003
versions, I have never observed this problem before with text files so I
cannot suggest a reason.

--

Ken Snell
<MS ACCESS MVP>

Not sure why you don't get the desired result, but what I suggest you do
is
to import the data to an empty table, then use an append query to copy the
data to a permanent table whose fields are indexed the way you want.

That is what I going to do but in such a way with the Access 97 as
with the Access 2003 the same problem occur. If I terminate the import
through the menu/external data the table is build successfully. Is
there any reason and explication for that happen?
[]'s
BD

 

[BD]

If your question is, why does the same thing happen with 97 and 2003
versions, I have never observed this problem before with text files so I
cannot suggest a reason.

Do you have any sample that use TransferText without this related
problem. One that have a Specification saved in the database and with
a primary key?
[]'s
BD

 

[Ken Snell \(MVP\)]

I'll have to look through my files and see... may take me a day or so to get
back to you.

--

Ken Snell
<MS ACCESS MVP>

If your question is, why does the same thing happen with 97 and 2003
versions, I have never observed this problem before with text files so I
cannot suggest a reason.

Do you have any sample that use TransferText without this related
problem. One that have a Specification saved in the database and with
a primary key?
[]'s
BD

 

[Ken Snell \(MVP\)]

I've reread through our thread, and I think I misunderstood your initial
question. When you said you had saved a specification with a primary key, I
was assuming that you meant that the primary key was in the table into which
you were importing the data. But I think now that you meant that, when you
first imported a file and saved the settings as a specification, you also
had set one of the fields in the imported text file to be your "own" primary
key. Is this correct?

If it is, the import specification that you save does not also save which
field was indicated to be the primary key. The only way to do that is to
import the file manually and set that value as part of the import process.

If you want to have the same primary key each time, then you need to do what
I suggested -- import to a temporary table, then use an append query to copy
the data to a table where the primary key has been defined already.

Sorry for having misled you in my answers.

--

Ken Snell
<MS ACCESS MVP>

If your question is, why does the same thing happen with 97 and 2003
versions, I have never observed this problem before with text files so I
cannot suggest a reason.

Do you have any sample that use TransferText without this related
problem. One that have a Specification saved in the database and with
a primary key?
[]'s
BD

 

[Ken Snell \(MVP\)]

I've reread through our thread, and I think I misunderstood your initial
question. When you said you had saved a specification with a primary key, I
was assuming that you meant that the primary key was in the table into which
you were importing the data. But I think now that you meant that, when you
first imported a file and saved the settings as a specification, you also
had set one of the fields in the imported text file to be your "own" primary
key. Is this correct?

If it is, the import specification that you save does not also save which
field was indicated to be the primary key. The only way to do that is to
import the file manually and set that value as part of the import process.

If you want to have the same primary key each time, then you need to do what
I suggested -- import to a temporary table, then use an append query to copy
the data to a table where the primary key has been defined already.

Sorry for having misled you in my answers.

--

Ken Snell
<MS ACCESS MVP>

If your question is, why does the same thing happen with 97 and 2003
versions, I have never observed this problem before with text files so I
cannot suggest a reason.

Do you have any sample that use TransferText without this related
problem. One that have a Specification saved in the database and with
a primary key?
[]'s
BD

 

[BD]

No problem, that is what I'm already doing. Thank you for your
confirmation.

[]'s
BD

 

[BD]

No problem, that is what I'm already doing. Thank you for your
confirmation.

[]'s
BD