Is IMPORT really asynchronous?

[wgcs]

Using this code:

IMPORT from (tcFile) TYPE XL5 SHEET (lcAlias)
lnFlds  = AFIELDS(laFlds)
SELECT (lcAlias)
GOTO TOP
COUNT TO lnCnt

I kept getting lnCnt=41 when executing in the program. If I stepped through, lnCnt=78.

I Added this after the IMPORT line:

DECLARE Sleep IN Win32Api AS apiSleep LONG dwMilliseconds
apiSleep( 200 )

And now it works right.
So, IMPORT seems to be an asynchronous. I don't like the idea of the 200ms delay being potentially too short... anyone have any ideas?

(As I type this, I thought of a loop that repeatedly trys to lock the .XLS file being imported, using FOPEN, but it's possible that VFP closes the XLS file before finishing adding to the new DBF...)

Alternatives I'd rather avoid are:
1) using automation to access the spreadsheet (it's just plain slow)
2) pre-creating a DBF and somehow appending from the spreadsheet... that would require me to know the format of the spreadsheet, and I want to be more general than that.
3) ODBC to Excel... too messy

- Bill

Get the best answers to your questions -- See FAQ481-4875.

 

[alvechurchdata]

What if you added a FLUSH immediately after the IMPORT? I wonder whether Fox is bright enough to know that it will have to complete the import before flushing.

More brutal
[TT]
IMPORT from (tcFile) TYPE XL5 SHEET (lcAlias)
USE IN lcAlias
.
.
.
USE (lcAlias) IN 0
SELECT (lcAlias)
GOTO TOP
COUNT TO lnCnt
[/TT]

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[wgcs]

Good idea!

- Bill

Get the best answers to your questions -- See FAQ481-4875.

 

[alvechurchdata]

Good idea!

That's very nice of you to say so.

You've got me worried though, I'd never even thought that IMPORT might be asynchronous and I'll be more careful in future. Thanks for raising the issue.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[Mike Lewis]

Bill,

This is really surprising. I don't disagree with your evidence. But this behaviour would never have occurred to me. It makes me wonder what other commands might behave this way.

(Actually, didn't you mean to say that the command is synchronous, that is, running at the same time? I think asynchronous is the term for one command running after the other. [If I'm talking rubbish it's because it's been a long day.])

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[wgcs]

I may have been wrong.

I don't fully understand what was going on; I found a bug that obscures the problem: I had reversed the Row and Column indexes on a DIMENSION statement, so even when IMPORT had completely finished, I was still getting only 40 rows. (There are 40 columns in the xls file).

The confusing part is that the times that it seemed IMPORT was not completing, I would get only 41 rows, but when I'd step through the code, I'd see all 78 rows.

It's hard to go back and re-trace steps to see just Where I saw the 78 rows... I probably kept stopping the debugger in disgust before getting to the DIMENSION statement....

(for the record, I had already looked at that dimension statement and evaluated to make sure I got the row/column right... I just made a mistake as I did so, and deliberately set them wrong)

Now, without the FLUSH, it all seems to be working perfectly, so I'm leaning towards my misinterpreting everything from the beginning.

Too often being frustrated makes perception less clear, just when it needs to be more acute.

- Bill

Get the best answers to your questions -- See FAQ481-4875.

 

[Mike Lewis]

Bill,

Even given the bug you mentioned, that wouldn't explain why your 200 ms sleep solved the problem. Still, I feel sure that IMPORT must work the same as other commands.

Perhaps someone could do a test with a large import file, in a PRG with no other code that might obscure the issue.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[thatguy]

out of curiosity, i tried it (using vfp8sp1).. with 62568 rows (and 32 columns), i ran the following (with excess time() calls):

CLOSE TABLES ALL 
CLEAR
IF FILE('outfile.dbf')
	DELETE FILE outfile.dbf
ENDIF  
SET SAFETY OFF 
?TIME()
IMPORT FROM outfile.xls TYPE XL8 SHEET outfile
?RECCOUNT('outfile')
?TIME()
?RECCOUNT('outfile')
SELECT outfile
?TIME()
GOTO TOP
?TIME()
COUNT TO lncnt
?TIME()
?lncnt
?TIME()
SET SAFETY ON

here's the output:

09:40:50
    62568
09:40:54
    62568
09:40:54
09:40:54
09:40:54
    62568
09:40:54

alas, it looks like it works just fine.. execution 'paused' after the 09:40:50 until all rows were imported, then went on to the rest...

--frank~

 

[wgcs]

I'm glad ThatGuy Frank did some confidence testing...

Mike:
...that wouldn't explain why your 200 ms sleep solved the problem...

Often the hardest to solve bugs are really misperceptions... and I think that's what I had here. I think the reason the sleep seemed to me to solve the problem is that I had set a breakpoint before the incorrect DIMENSION statement, and I was looking at RECCOUNT(), _TALLY, and "COUNT TO lnCnt" to see if they were correct, and they were!

Every time I went through slower (stepping, or adding the delay), I must have been checking the result too soon, so it seemed to work.

But when I let it run normally, my final output was always limited to 40 or 41 rows (there were 40 columns in the XLS), and my variable, lnCnt, was 40 or 41... lnCnt must have been re-calculated after the bad DIMENSION effectively truncated the length of the file.

( I don't have an explanation on how I got 41 rows when there were only 40 columns... this is the primary thing that threw me off the trail of the bad DIMENSION statement)

I thank everyone who gave thought to this issue, but I think IMPORT really is synchronous, as it should be.

- Bill

Get the best answers to your questions -- See FAQ481-4875.