Text import wizard does import properly beyond text file line 1048


B

Bas V

I have attempted again to get the text import feature of MS Excel 2007 to
work using a really long (10,402,255 lines) ascii format text data files with
two columns of fixed width fields. Despite the updates to the Excel 2007
program since I first tried this, the implementation of this feature remains
pitiful.

Here are my findings of how this feature of Excel behaves:

1. If you set up the text import to start on the first line of the
text source file and put them into your worksheet starting on cell A1, then
the importer will capture the first 1048576 lines and put them all into your
worksheet - so it works OK there and it is fast - about 14 seconds on my
machine. 1048576 is the maximum number of rows that you can accommodate on
a single worksheet in Excel 2007.

2. If you set up the importer to start on line 30,001 (which skips the
first 30000 lines), then the importer captures all the lines up to line
1048577 in the source text file. This means you will have two columns of
data up to row 1018577 in your worksheet. This is the first indication that
the text file importer cannot properly access lines in a source text file
beyond a maximum of the first 1048576 (2^20) lines. Attempts to start on
another line (e.g. 65001 will fill down to row 983577) shows behaviour
consistent with this observation. If you attempt an import starting on line
1048576 of a source text file, you will get exactly two rows of data - this
is again consistent (and bad).

3. If you start on line 1048577, then you get only one row and it only
fills in only the first cell of that row with the time data from line 1048577
- so you get the first column but not the second. The rest of the rows in
the 1048576 row text import range are then blank (as per import setting to
replace contents). Likewise, if you attempt to start on line 1048578, then
you still get only one row and it only fills in the first cell of that row
with the time data from line 1048578. It does this even for line 10402254 -
and then you still only got one cell of data from line 10402254 - plus it
takes a couple of minutes to do it.

4. The text import will work at all only as long as you have the
import range set up on a separate sheet. If you attempt to set up two import
data ranges next to one another on the same sheet, then Excel will quit
"unexpectedly" when you try to update the data connection - i.e. it crashes.
I found similar stupid behaviour when you have formulae to the right of the
import range - it either crashes or takes hours (instead of a few seconds) to
complete the operation.

The bad behaviour beyond text file line 1048576 is obviously not what the
Excel programmers intended. The program displays the following friendly
advice when you start your test import on line 1 of a really large text file:

"The text file contains more data then will fit on a single worksheet. To
continue and import as much of the data as will fit, click OK. You can then
import the rest of the data by repeating the import operation on another
worksheet and using the Text Import Wizard to exclude data already imported"

The fact is that you can't.

The indications are that the "Text Import Wizard" is built with text file
line addressing that only uses 20 bits - more like a "Text Import Doofus."
Too bad too, since my calculations indicate that if it worked properly, I
would be able to parse a 10,000,000 line text file with two fixed width
columns into Excel worksheet cells in about 2.5 minutes rather than the ~75
minutes the stripped down vba script I had to write takes to do it line by
line; this was the "solution" offered by a guy in Microsoft Premiere tech
support. I also noted that both vba and the "wizard" use only one processor.

Is there prospect that Microsoft will wise up this Wizard and make it work
correctly??
 
Ad

Advertisements

N

Niek Otten

The maximum number of lines in any Excel2007 sheet is 1,048,567
That's 16 times what it used to be


--
Kind regards,

Niek Otten
Microsoft MVP - Excel

|I have attempted again to get the text import feature of MS Excel 2007 to
| work using a really long (10,402,255 lines) ascii format text data files with
| two columns of fixed width fields. Despite the updates to the Excel 2007
| program since I first tried this, the implementation of this feature remains
| pitiful.
|
| Here are my findings of how this feature of Excel behaves:
|
| 1. If you set up the text import to start on the first line of the
| text source file and put them into your worksheet starting on cell A1, then
| the importer will capture the first 1048576 lines and put them all into your
| worksheet - so it works OK there and it is fast - about 14 seconds on my
| machine. 1048576 is the maximum number of rows that you can accommodate on
| a single worksheet in Excel 2007.
|
| 2. If you set up the importer to start on line 30,001 (which skips the
| first 30000 lines), then the importer captures all the lines up to line
| 1048577 in the source text file. This means you will have two columns of
| data up to row 1018577 in your worksheet. This is the first indication that
| the text file importer cannot properly access lines in a source text file
| beyond a maximum of the first 1048576 (2^20) lines. Attempts to start on
| another line (e.g. 65001 will fill down to row 983577) shows behaviour
| consistent with this observation. If you attempt an import starting on line
| 1048576 of a source text file, you will get exactly two rows of data - this
| is again consistent (and bad).
|
| 3. If you start on line 1048577, then you get only one row and it only
| fills in only the first cell of that row with the time data from line 1048577
| - so you get the first column but not the second. The rest of the rows in
| the 1048576 row text import range are then blank (as per import setting to
| replace contents). Likewise, if you attempt to start on line 1048578, then
| you still get only one row and it only fills in the first cell of that row
| with the time data from line 1048578. It does this even for line 10402254 -
| and then you still only got one cell of data from line 10402254 - plus it
| takes a couple of minutes to do it.
|
| 4. The text import will work at all only as long as you have the
| import range set up on a separate sheet. If you attempt to set up two import
| data ranges next to one another on the same sheet, then Excel will quit
| "unexpectedly" when you try to update the data connection - i.e. it crashes.
| I found similar stupid behaviour when you have formulae to the right of the
| import range - it either crashes or takes hours (instead of a few seconds) to
| complete the operation.
|
| The bad behaviour beyond text file line 1048576 is obviously not what the
| Excel programmers intended. The program displays the following friendly
| advice when you start your test import on line 1 of a really large text file:
|
| "The text file contains more data then will fit on a single worksheet. To
| continue and import as much of the data as will fit, click OK. You can then
| import the rest of the data by repeating the import operation on another
| worksheet and using the Text Import Wizard to exclude data already imported"
|
| The fact is that you can't.
|
| The indications are that the "Text Import Wizard" is built with text file
| line addressing that only uses 20 bits - more like a "Text Import Doofus."
| Too bad too, since my calculations indicate that if it worked properly, I
| would be able to parse a 10,000,000 line text file with two fixed width
| columns into Excel worksheet cells in about 2.5 minutes rather than the ~75
| minutes the stripped down vba script I had to write takes to do it line by
| line; this was the "solution" offered by a guy in Microsoft Premiere tech
| support. I also noted that both vba and the "wizard" use only one processor.
|
| Is there prospect that Microsoft will wise up this Wizard and make it work
| correctly??
|
|
| --
| Bas V
 
B

Bas V

Thank you for your post - but the importer should work on large files even
with the limitation you point out. Here is how:

If you carefuly read my entire previous post, then you will see that it
actually states the maximum number of rows (not lines) that Excel supports in
a worksheet is indeed 1048576. However, that does not mean that the text
import wizard should only be able to imort the first 1048576 lines from a
text file; it should be able to start from line 1048577 and import the next
1048576 lines and so on. Version 2007 cannot do this because it is broken.
This is also a feature of Excel 2003, when you can only import 65K lines at a
time. Repeating imports and skipping actually works in version 2003, so you
can import 10 million lines - it just takes about 300 sheets to do it. There
are a number of web pages that talk about this technique - it has been around
for a while. Theoretically Excel 2007 shoul be able handel a 10 million line
text filewith just 10 sheets, if Microsoft would fix it to work as it should.

Bas V
 
N

Niek Otten

Hi Bas,

Sorry I misread your question at first.

Not at all my area of expertise, but I tried this:

Sub SchrijfTextFile()
Dim i As Long
Open "C:\AFile.txt" For Output As #1
For i = 1 To [a1]
Write #1, i
Next i
Close #1
End Sub

With 2,000,000 in A1.

I then read the file into Excel and of course it told me that not all the data was loaded.
I then instructed Excel to start with row number 1,000,000 (in the Text import wizard) and it worked fine. Started with 1,000,000
and included the rest of the file.

Something with the way records are terminated?

--
Kind regards,

Niek Otten
Microsoft MVP - Excel




| Thank you for your post - but the importer should work on large files even
| with the limitation you point out. Here is how:
|
| If you carefuly read my entire previous post, then you will see that it
| actually states the maximum number of rows (not lines) that Excel supports in
| a worksheet is indeed 1048576. However, that does not mean that the text
| import wizard should only be able to imort the first 1048576 lines from a
| text file; it should be able to start from line 1048577 and import the next
| 1048576 lines and so on. Version 2007 cannot do this because it is broken.
| This is also a feature of Excel 2003, when you can only import 65K lines at a
| time. Repeating imports and skipping actually works in version 2003, so you
| can import 10 million lines - it just takes about 300 sheets to do it. There
| are a number of web pages that talk about this technique - it has been around
| for a while. Theoretically Excel 2007 shoul be able handel a 10 million line
| text filewith just 10 sheets, if Microsoft would fix it to work as it should.
|
| Bas V
|
|
| "Niek Otten" wrote:
|
| > The maximum number of lines in any Excel2007 sheet is 1,048,567
| > That's 16 times what it used to be
| >
| >
| > --
| > Kind regards,
| >
| > Niek Otten
| > Microsoft MVP - Excel
| >
| > |I have attempted again to get the text import feature of MS Excel 2007 to
| > | work using a really long (10,402,255 lines) ascii format text data files with
| > | two columns of fixed width fields. Despite the updates to the Excel 2007
| > | program since I first tried this, the implementation of this feature remains
| > | pitiful.
| > |
| > | Here are my findings of how this feature of Excel behaves:
| > |
| > | 1. If you set up the text import to start on the first line of the
| > | text source file and put them into your worksheet starting on cell A1, then
| > | the importer will capture the first 1048576 lines and put them all into your
| > | worksheet - so it works OK there and it is fast - about 14 seconds on my
| > | machine. 1048576 is the maximum number of rows that you can accommodate on
| > | a single worksheet in Excel 2007.
| > |
| > | 2. If you set up the importer to start on line 30,001 (which skips the
| > | first 30000 lines), then the importer captures all the lines up to line
| > | 1048577 in the source text file. This means you will have two columns of
| > | data up to row 1018577 in your worksheet. This is the first indication that
| > | the text file importer cannot properly access lines in a source text file
| > | beyond a maximum of the first 1048576 (2^20) lines. Attempts to start on
| > | another line (e.g. 65001 will fill down to row 983577) shows behaviour
| > | consistent with this observation. If you attempt an import starting on line
| > | 1048576 of a source text file, you will get exactly two rows of data - this
| > | is again consistent (and bad).
| > |
| > | 3. If you start on line 1048577, then you get only one row and it only
| > | fills in only the first cell of that row with the time data from line 1048577
| > | - so you get the first column but not the second. The rest of the rows in
| > | the 1048576 row text import range are then blank (as per import setting to
| > | replace contents). Likewise, if you attempt to start on line 1048578, then
| > | you still get only one row and it only fills in the first cell of that row
| > | with the time data from line 1048578. It does this even for line 10402254 -
| > | and then you still only got one cell of data from line 10402254 - plus it
| > | takes a couple of minutes to do it.
| > |
| > | 4. The text import will work at all only as long as you have the
| > | import range set up on a separate sheet. If you attempt to set up two import
| > | data ranges next to one another on the same sheet, then Excel will quit
| > | "unexpectedly" when you try to update the data connection - i.e. it crashes.
| > | I found similar stupid behaviour when you have formulae to the right of the
| > | import range - it either crashes or takes hours (instead of a few seconds) to
| > | complete the operation.
| > |
| > | The bad behaviour beyond text file line 1048576 is obviously not what the
| > | Excel programmers intended. The program displays the following friendly
| > | advice when you start your test import on line 1 of a really large text file:
| > |
| > | "The text file contains more data then will fit on a single worksheet. To
| > | continue and import as much of the data as will fit, click OK. You can then
| > | import the rest of the data by repeating the import operation on another
| > | worksheet and using the Text Import Wizard to exclude data already imported"
| > |
| > | The fact is that you can't.
| > |
| > | The indications are that the "Text Import Wizard" is built with text file
| > | line addressing that only uses 20 bits - more like a "Text Import Doofus."
| > | Too bad too, since my calculations indicate that if it worked properly, I
| > | would be able to parse a 10,000,000 line text file with two fixed width
| > | columns into Excel worksheet cells in about 2.5 minutes rather than the ~75
| > | minutes the stripped down vba script I had to write takes to do it line by
| > | line; this was the "solution" offered by a guy in Microsoft Premiere tech
| > | support. I also noted that both vba and the "wizard" use only one processor.
| > |
| > | Is there prospect that Microsoft will wise up this Wizard and make it work
| > | correctly??
| > |
| > |
| > | --
| > | Bas V
| >
| >
| >
 
B

Bas V

Greetings again Niek and thank you for the follow-up. Erg goeieg van U.

I inspected my text file with TextPad (opens a lot faster than with Notepad)
- nothing there but numbers, decimals, signs, spaces, and paragraph marks -
as expected. I resaved it as a DOS file - got the same exact size as the old
file and the same behaviour on import. I tried it with fixed field
delimiters and as a single column of 30 character strings - all imports stop
on line 1048577 and will only get one line for imports starting any deeper
into the source text file.

I ran the macro and made a test file with 10000000 lines - that ran real
fast - I can use that regardless. However, the import to Excel still behaves
the same. It does not work right with only 2000000 lines in the source file
either.

Since it apparently works on another system, I am beginning to think that
perhaps something is up with mine. I have XP 32 bit with Excel 2007
installed separately. The rest of the Office software (all except Excel)
that I have is still the 2003 version. I am going home and try it on a XP-32
laptop with a full 2007 Office install. If that works, then maybe I have a
fix. If not, then I will be interested to know if you are by any chance
running a 64 bit OS.

Veel Dank.
--
Bas V


Niek Otten said:
Hi Bas,

Sorry I misread your question at first.

Not at all my area of expertise, but I tried this:

Sub SchrijfTextFile()
Dim i As Long
Open "C:\AFile.txt" For Output As #1
For i = 1 To [a1]
Write #1, i
Next i
Close #1
End Sub

With 2,000,000 in A1.

I then read the file into Excel and of course it told me that not all the data was loaded.
I then instructed Excel to start with row number 1,000,000 (in the Text import wizard) and it worked fine. Started with 1,000,000
and included the rest of the file.

Something with the way records are terminated?

--
Kind regards,

Niek Otten
Microsoft MVP - Excel




| Thank you for your post - but the importer should work on large files even
| with the limitation you point out. Here is how:
|
| If you carefuly read my entire previous post, then you will see that it
| actually states the maximum number of rows (not lines) that Excel supports in
| a worksheet is indeed 1048576. However, that does not mean that the text
| import wizard should only be able to imort the first 1048576 lines from a
| text file; it should be able to start from line 1048577 and import the next
| 1048576 lines and so on. Version 2007 cannot do this because it is broken.
| This is also a feature of Excel 2003, when you can only import 65K lines at a
| time. Repeating imports and skipping actually works in version 2003, so you
| can import 10 million lines - it just takes about 300 sheets to do it. There
| are a number of web pages that talk about this technique - it has been around
| for a while. Theoretically Excel 2007 shoul be able handel a 10 million line
| text filewith just 10 sheets, if Microsoft would fix it to work as it should.
|
| Bas V
|
|
| "Niek Otten" wrote:
|
| > The maximum number of lines in any Excel2007 sheet is 1,048,567
| > That's 16 times what it used to be
| >
| >
| > --
| > Kind regards,
| >
| > Niek Otten
| > Microsoft MVP - Excel
| >
| > |I have attempted again to get the text import feature of MS Excel 2007 to
| > | work using a really long (10,402,255 lines) ascii format text data files with
| > | two columns of fixed width fields. Despite the updates to the Excel 2007
| > | program since I first tried this, the implementation of this feature remains
| > | pitiful.
| > |
| > | Here are my findings of how this feature of Excel behaves:
| > |
| > | 1. If you set up the text import to start on the first line of the
| > | text source file and put them into your worksheet starting on cell A1, then
| > | the importer will capture the first 1048576 lines and put them all into your
| > | worksheet - so it works OK there and it is fast - about 14 seconds on my
| > | machine. 1048576 is the maximum number of rows that you can accommodate on
| > | a single worksheet in Excel 2007.
| > |
| > | 2. If you set up the importer to start on line 30,001 (which skips the
| > | first 30000 lines), then the importer captures all the lines up to line
| > | 1048577 in the source text file. This means you will have two columns of
| > | data up to row 1018577 in your worksheet. This is the first indication that
| > | the text file importer cannot properly access lines in a source text file
| > | beyond a maximum of the first 1048576 (2^20) lines. Attempts to start on
| > | another line (e.g. 65001 will fill down to row 983577) shows behaviour
| > | consistent with this observation. If you attempt an import starting on line
| > | 1048576 of a source text file, you will get exactly two rows of data - this
| > | is again consistent (and bad).
| > |
| > | 3. If you start on line 1048577, then you get only one row and it only
| > | fills in only the first cell of that row with the time data from line 1048577
| > | - so you get the first column but not the second. The rest of the rows in
| > | the 1048576 row text import range are then blank (as per import setting to
| > | replace contents). Likewise, if you attempt to start on line 1048578, then
| > | you still get only one row and it only fills in the first cell of that row
| > | with the time data from line 1048578. It does this even for line 10402254 -
| > | and then you still only got one cell of data from line 10402254 - plus it
| > | takes a couple of minutes to do it.
| > |
| > | 4. The text import will work at all only as long as you have the
| > | import range set up on a separate sheet. If you attempt to set up two import
| > | data ranges next to one another on the same sheet, then Excel will quit
| > | "unexpectedly" when you try to update the data connection - i.e. it crashes.
| > | I found similar stupid behaviour when you have formulae to the right of the
| > | import range - it either crashes or takes hours (instead of a few seconds) to
| > | complete the operation.
| > |
| > | The bad behaviour beyond text file line 1048576 is obviously not what the
| > | Excel programmers intended. The program displays the following friendly
| > | advice when you start your test import on line 1 of a really large text file:
| > |
| > | "The text file contains more data then will fit on a single worksheet. To
| > | continue and import as much of the data as will fit, click OK. You can then
| > | import the rest of the data by repeating the import operation on another
| > | worksheet and using the Text Import Wizard to exclude data already imported"
| > |
| > | The fact is that you can't.
| > |
| > | The indications are that the "Text Import Wizard" is built with text file
| > | line addressing that only uses 20 bits - more like a "Text Import Doofus."
| > | Too bad too, since my calculations indicate that if it worked properly, I
| > | would be able to parse a 10,000,000 line text file with two fixed width
| > | columns into Excel worksheet cells in about 2.5 minutes rather than the ~75
| > | minutes the stripped down vba script I had to write takes to do it line by
| > | line; this was the "solution" offered by a guy in Microsoft Premiere tech
| > | support. I also noted that both vba and the "wizard" use only one processor.
| > |
| > | Is there prospect that Microsoft will wise up this Wizard and make it work
| > | correctly??
| > |
| > |
| > | --
| > | Bas V
| >
| >
| >
 
Ad

Advertisements

B

Bas V

Attempts to use the text import wizard on very long text files generated by
Niek Otten's script still did not work on a "clean" copy of Excel 2007 as
part of an Office 2007 installedon a Pentium M laptop (2 GB ram) running Win
XP-32 bit. The same behaviour, where the import facility fails beyond line
1048576 of the source text file is observed.

If anybody out there can get this to work, can you please tell me if it is
on a 64 bit system?
--
Bas V


Bas V said:
Greetings again Niek and thank you for the follow-up. Erg goeieg van U.

I inspected my text file with TextPad (opens a lot faster than with Notepad)
- nothing there but numbers, decimals, signs, spaces, and paragraph marks -
as expected. I resaved it as a DOS file - got the same exact size as the old
file and the same behaviour on import. I tried it with fixed field
delimiters and as a single column of 30 character strings - all imports stop
on line 1048577 and will only get one line for imports starting any deeper
into the source text file.

I ran the macro and made a test file with 10000000 lines - that ran real
fast - I can use that regardless. However, the import to Excel still behaves
the same. It does not work right with only 2000000 lines in the source file
either.

Since it apparently works on another system, I am beginning to think that
perhaps something is up with mine. I have XP 32 bit with Excel 2007
installed separately. The rest of the Office software (all except Excel)
that I have is still the 2003 version. I am going home and try it on a XP-32
laptop with a full 2007 Office install. If that works, then maybe I have a
fix. If not, then I will be interested to know if you are by any chance
running a 64 bit OS.

Veel Dank.
--
Bas V


Niek Otten said:
Hi Bas,

Sorry I misread your question at first.

Not at all my area of expertise, but I tried this:

Sub SchrijfTextFile()
Dim i As Long
Open "C:\AFile.txt" For Output As #1
For i = 1 To [a1]
Write #1, i
Next i
Close #1
End Sub

With 2,000,000 in A1.

I then read the file into Excel and of course it told me that not all the data was loaded.
I then instructed Excel to start with row number 1,000,000 (in the Text import wizard) and it worked fine. Started with 1,000,000
and included the rest of the file.

Something with the way records are terminated?

--
Kind regards,

Niek Otten
Microsoft MVP - Excel




| Thank you for your post - but the importer should work on large files even
| with the limitation you point out. Here is how:
|
| If you carefuly read my entire previous post, then you will see that it
| actually states the maximum number of rows (not lines) that Excel supports in
| a worksheet is indeed 1048576. However, that does not mean that the text
| import wizard should only be able to imort the first 1048576 lines from a
| text file; it should be able to start from line 1048577 and import the next
| 1048576 lines and so on. Version 2007 cannot do this because it is broken.
| This is also a feature of Excel 2003, when you can only import 65K lines at a
| time. Repeating imports and skipping actually works in version 2003, so you
| can import 10 million lines - it just takes about 300 sheets to do it. There
| are a number of web pages that talk about this technique - it has been around
| for a while. Theoretically Excel 2007 shoul be able handel a 10 million line
| text filewith just 10 sheets, if Microsoft would fix it to work as it should.
|
| Bas V
|
|
| "Niek Otten" wrote:
|
| > The maximum number of lines in any Excel2007 sheet is 1,048,567
| > That's 16 times what it used to be
| >
| >
| > --
| > Kind regards,
| >
| > Niek Otten
| > Microsoft MVP - Excel
| >
| > |I have attempted again to get the text import feature of MS Excel 2007 to
| > | work using a really long (10,402,255 lines) ascii format text data files with
| > | two columns of fixed width fields. Despite the updates to the Excel 2007
| > | program since I first tried this, the implementation of this feature remains
| > | pitiful.
| > |
| > | Here are my findings of how this feature of Excel behaves:
| > |
| > | 1. If you set up the text import to start on the first line of the
| > | text source file and put them into your worksheet starting on cell A1, then
| > | the importer will capture the first 1048576 lines and put them all into your
| > | worksheet - so it works OK there and it is fast - about 14 seconds on my
| > | machine. 1048576 is the maximum number of rows that you can accommodate on
| > | a single worksheet in Excel 2007.
| > |
| > | 2. If you set up the importer to start on line 30,001 (which skips the
| > | first 30000 lines), then the importer captures all the lines up to line
| > | 1048577 in the source text file. This means you will have two columns of
| > | data up to row 1018577 in your worksheet. This is the first indication that
| > | the text file importer cannot properly access lines in a source text file
| > | beyond a maximum of the first 1048576 (2^20) lines. Attempts to start on
| > | another line (e.g. 65001 will fill down to row 983577) shows behaviour
| > | consistent with this observation. If you attempt an import starting on line
| > | 1048576 of a source text file, you will get exactly two rows of data - this
| > | is again consistent (and bad).
| > |
| > | 3. If you start on line 1048577, then you get only one row and it only
| > | fills in only the first cell of that row with the time data from line 1048577
| > | - so you get the first column but not the second. The rest of the rows in
| > | the 1048576 row text import range are then blank (as per import setting to
| > | replace contents). Likewise, if you attempt to start on line 1048578, then
| > | you still get only one row and it only fills in the first cell of that row
| > | with the time data from line 1048578. It does this even for line 10402254 -
| > | and then you still only got one cell of data from line 10402254 - plus it
| > | takes a couple of minutes to do it.
| > |
| > | 4. The text import will work at all only as long as you have the
| > | import range set up on a separate sheet. If you attempt to set up two import
| > | data ranges next to one another on the same sheet, then Excel will quit
| > | "unexpectedly" when you try to update the data connection - i.e. it crashes.
| > | I found similar stupid behaviour when you have formulae to the right of the
| > | import range - it either crashes or takes hours (instead of a few seconds) to
| > | complete the operation.
| > |
| > | The bad behaviour beyond text file line 1048576 is obviously not what the
| > | Excel programmers intended. The program displays the following friendly
| > | advice when you start your test import on line 1 of a really large text file:
| > |
| > | "The text file contains more data then will fit on a single worksheet. To
| > | continue and import as much of the data as will fit, click OK. You can then
| > | import the rest of the data by repeating the import operation on another
| > | worksheet and using the Text Import Wizard to exclude data already imported"
| > |
| > | The fact is that you can't.
| > |
| > | The indications are that the "Text Import Wizard" is built with text file
| > | line addressing that only uses 20 bits - more like a "Text Import Doofus."
| > | Too bad too, since my calculations indicate that if it worked properly, I
| > | would be able to parse a 10,000,000 line text file with two fixed width
| > | columns into Excel worksheet cells in about 2.5 minutes rather than the ~75
| > | minutes the stripped down vba script I had to write takes to do it line by
| > | line; this was the "solution" offered by a guy in Microsoft Premiere tech
| > | support. I also noted that both vba and the "wizard" use only one processor.
| > |
| > | Is there prospect that Microsoft will wise up this Wizard and make it work
| > | correctly??
| > |
| > |
| > | --
| > | Bas V
| >
| >
| >
 
Ad

Advertisements


Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top