Import Specification

  • Thread starter Thread starter BD
  • Start date Start date
B

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
 
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.
 
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.
Click to expand...
[]'s
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.

--

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.
Click to expand...
[]'s
BD
Click to expand...
 
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.
Click to expand...


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
 
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.
Click to expand...


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
Click to expand...
 
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.
Click to expand...


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
 
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.
Click to expand...


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
Click to expand...
 
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.
Click to expand...


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
Click to expand...
 
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.
Click to expand...


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
Click to expand...
 
Back
Top