Bad Validation Does Not Generate A Tablename$_ImportErrors Table

[azimuthdba]

Thanks in Advance,

I am importing from Excel 2003 into Access 2003 a sheet into a pre-
designed table with validation that a Char(8) had to have all 8
characters poplulated. Out of 280 rows it fails to import 64 rows due
to have only 6 or 7 characters in the field. This behavior is fine,
but it does not generate an import errors table as I have seen in the
past.

Is this a toggled behavior that I can somehow turn back on? I
verified in the help files under troubleshoot importing the field
validation should generate an error log table.

Mark S
Napa, California

 

[Jeff Boyce]

Mark

If you know already that some of the rows don't have 8 characters in the
field, why are you requiring the field to have 8 characters?

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[azimuthdba]

Mark

If you know already that some of the rows don't have 8 characters in the
field, why are you requiring the field to have 8 characters?

Regards

Jeff Boyce
Microsoft Office/Access MVP









- Show quoted text -

Because the ultimate destination requires 8 characters and the access
table is providing validation out of a free form Excel spreadsheet. I
want the feature of the import errors table.

Do you know how I can generate the Tablename$_ImportErrors table?

Mark

 

[tina]

if your goal here is to identify the the rows that have less than 8
characters in a particular cell - for data cleanup? - you could just import
all the data without the 8-character restriction. then write a Select query,
including a calculated field that counts the number of characters in the
data field for each record, as

CharCount: Len([Fieldname])

replace Fieldname with the name of the field where you want to count the
number of characters, and add criteria to the calculated field CharCount, to
see only the offending records, as

<8

hth

Mark

If you know already that some of the rows don't have 8 characters in the
field, why are you requiring the field to have 8 characters?

Regards

Jeff Boyce
Microsoft Office/Access MVP









- Show quoted text -

Because the ultimate destination requires 8 characters and the access
table is providing validation out of a free form Excel spreadsheet. I
want the feature of the import errors table.

Do you know how I can generate the Tablename$_ImportErrors table?

Mark

 

[Jeff Boyce]

I'm with Tina on this...

Import what you have ... don't 'validate' it on import. I'll guess that
your need is not to alter the raw data, but to "condition" it before export.

Before exporting, use a query to convert the raw import data to the format
needed. Doug Steele the other day offered a simple way to zero-pad a field
that was less than 'n' characters. You could use:

Right("00000000" & [YourImportField],8)

to create your output field in a query.

Regards

Jeff Boyce
Microsoft Office/Access MVP

Mark

If you know already that some of the rows don't have 8 characters in the
field, why are you requiring the field to have 8 characters?

Regards

Jeff Boyce
Microsoft Office/Access MVP









- Show quoted text -

Because the ultimate destination requires 8 characters and the access
table is providing validation out of a free form Excel spreadsheet. I
want the feature of the import errors table.

Do you know how I can generate the Tablename$_ImportErrors table?

Mark

 

[azimuthdba]

if your goal here is to identify the the rows that have less than 8
characters in a particular cell - for data cleanup? - you could just import
all the data without the 8-character restriction. then write a Select query,
including a calculated field that counts the number of characters in the
data field for each record, as

CharCount: Len([Fieldname])

replace Fieldname with the name of the field where you want to count the
number of characters, and add criteria to the calculated field CharCount,to
see only the offending records, as

<8

hth

Mark

If you know already that some of the rows don't have 8 characters in the
field, why are you requiring the field to have 8 characters?

Jeff Boyce
Microsoft Office/Access MVP

- Show quoted text -

Because the ultimate destination requires 8 characters and the access
table is providing validation out of a free form Excel spreadsheet.  I
want the feature of the import errors table.

Do you know how I can generate the Tablename$_ImportErrors table?

Mark- Hide quoted text -

- Show quoted text -

Let's make this simple. Someone please walk me through a scenario
that creates a Tablename$_ImportErrors importing data from Excel to
Access. Based on the responses that I have seen I do not believe
anyone can.

Thanks Tina, but that was not my goal. I want to generate the
Tablename$_ImportErrors for its own sake. Does anyone know why it
will not generate with validation errors?

Mark

 

[azimuthdba]

I'm with Tina on this...

Import what you have ... don't 'validate' it on import.  I'll guess that
your need is not to alter the raw data, but to "condition" it before export.

Before exporting, use a query to convert the raw import data to the format
needed.  Doug Steele the other day offered a simple way to zero-pad a field
that was less than 'n' characters.  You could use:

    Right("00000000" & [YourImportField],8)

to create your output field in a query.

Regards

Jeff Boyce
Microsoft Office/Access MVP

Mark

If you know already that some of the rows don't have 8 characters in the
field, why are you requiring the field to have 8 characters?

Jeff Boyce
Microsoft Office/Access MVP

- Show quoted text -

Because the ultimate destination requires 8 characters and the access
table is providing validation out of a free form Excel spreadsheet.  I
want the feature of the import errors table.

Do you know how I can generate the Tablename$_ImportErrors table?

Mark- Hide quoted text -

- Show quoted text -

Thanks Jeff, but I do not have space to write all the reasons why I
want this. If you do not know why the Tablename$_ImportErrors table
will not generate, then please just say so. Zero padding would be
disasterous in my case and it's exactly what I am trying to avoid.

Mark

 

[Jeff Boyce]

Mark

We can only offer ideas based on the description provided (or speculate
....<g>).

I have no idea why you aren't receiving an import error table.

If you tighten down too much on what (and how) you want to do something, you
risk missing ideas from folks who may know a way to help that wasn't part of
your initial understanding/experience.

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

I'm with Tina on this...

Import what you have ... don't 'validate' it on import. I'll guess that
your need is not to alter the raw data, but to "condition" it before
export.

Before exporting, use a query to convert the raw import data to the format
needed. Doug Steele the other day offered a simple way to zero-pad a field
that was less than 'n' characters. You could use:

Right("00000000" & [YourImportField],8)

to create your output field in a query.

Regards

Jeff Boyce
Microsoft Office/Access MVP

Mark

If you know already that some of the rows don't have 8 characters in the
field, why are you requiring the field to have 8 characters?

Jeff Boyce
Microsoft Office/Access MVP

- Show quoted text -

Because the ultimate destination requires 8 characters and the access
table is providing validation out of a free form Excel spreadsheet. I
want the feature of the import errors table.

Do you know how I can generate the Tablename$_ImportErrors table?

Mark- Hide quoted text -

- Show quoted text -

Thanks Jeff, but I do not have space to write all the reasons why I
want this. If you do not know why the Tablename$_ImportErrors table
will not generate, then please just say so. Zero padding would be
disasterous in my case and it's exactly what I am trying to avoid.

Mark

 

[tina]

i'm with Jeff on this. and to give the simple answer requested: i don't
know why.

Mark

We can only offer ideas based on the description provided (or speculate
...<g>).

I have no idea why you aren't receiving an import error table.

If you tighten down too much on what (and how) you want to do something, you
risk missing ideas from folks who may know a way to help that wasn't part of
your initial understanding/experience.

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

I'm with Tina on this...

Import what you have ... don't 'validate' it on import. I'll guess that
your need is not to alter the raw data, but to "condition" it before
export.

Before exporting, use a query to convert the raw import data to the format
needed. Doug Steele the other day offered a simple way to zero-pad a field
that was less than 'n' characters. You could use:

Right("00000000" & [YourImportField],8)

to create your output field in a query.

Regards

Jeff Boyce
Microsoft Office/Access MVP

Mark

If you know already that some of the rows don't have 8 characters in the
field, why are you requiring the field to have 8 characters?

Jeff Boyce
Microsoft Office/Access MVP

Thanks in Advance,

I am importing from Excel 2003 into Access 2003 a sheet into a pre-
designed table with validation that a Char(8) had to have all 8
characters poplulated. Out of 280 rows it fails to import 64 rows due
to have only 6 or 7 characters in the field. This behavior is fine,
but it does not generate an import errors table as I have seen in the
past.

Is this a toggled behavior that I can somehow turn back on? I
verified in the help files under troubleshoot importing the field
validation should generate an error log table.

Mark S
Napa, California- Hide quoted text -

- Show quoted text -

Because the ultimate destination requires 8 characters and the access
table is providing validation out of a free form Excel spreadsheet. I
want the feature of the import errors table.

Do you know how I can generate the Tablename$_ImportErrors table?

Mark- Hide quoted text -

- Show quoted text -

Thanks Jeff, but I do not have space to write all the reasons why I
want this. If you do not know why the Tablename$_ImportErrors table
will not generate, then please just say so. Zero padding would be
disasterous in my case and it's exactly what I am trying to avoid.

Mark