I have had an ASCII import running for ten years on an arev system with no problems. The file is generated by another computer system and copied to this computer to be imported.

Twice in the last two months there has been one record in each of two different files that have merged together. Part of one record is appended to another record. The record that is appended is only partially there while the other record is complete.

I'm using 13,10 as the delimiters and 26 as end of file as usual.

There is nothing strange in either file. I've searched for any control characters and there is nothing in the file that would account for this.

Now the fun part. If I edit the text file and make any change to it (ANY) the import works. I can add a space to any line. I can change a character say an "A" to a "B" in any line and it works. If I change it back it acts up the same way.

Now for the most fun part. It has happened so far in 10 years on only these two files and files generated in between work perfectly and I have no idea what the problem is.

Do the affected records span either 32K or 64K characters? There is an infamous bug at one of those points (sorry, I've forgotten which.)

Did you build your own import routine, or did you use a built in one? What method are you using to modify the file when you, for example, change and A to a B?

The original DOS files have ranged in size from 400K to 700K. I'll check to see if the two records that are affected are on a boundary, but the files that have been imported for ten years have all been in this range and it has never happened before. I have enough checks to detect any bytes out of place just out of habit, and it hasn't happened before.

I toyed with using my own import ten years ago, but in the end the built in routine worked fine and up until now wasn't a problem.

I used a hex editor to change characters as well as to check for any weird characters in the DOS file. I compared byte counts before and after editing to keep track of what I was doing. I could add a character somewhere as well as delete one anywhere in the file and the import worked.

I even opened the file with WordPerfect to use the view mode and search for something that would cause this.

I tried four different copies of AREV and it still comes up the same.

Adding and deleting a characters are one thing. Another thing altogether is changing a character. This is an important distinction if the problem is, for example, that the CR and LF fall on different blocks of the read operation. I don't use the built in utility because I've always had some problem or another with it, and rolling my own seemed to be the most realiable and fastest method. So I don't know if it's vulnerable to this sort of issue.

I've seen problems with line separators being inconsistent (CR LF, CR, LF, or some mix). If I had the problem you're describing, that's probably what I would check for first.

I'd volunteer to take a look at your file and import template, but I'm not sure what the best way would be to do that, since I'd need to have your dictionary, too, or at least that portion that's referenced in the import template. If you care to package everything in a zip file and send it on, you can email it to brillig at gmail.com, and I'll take a look.

Victor

I can't send the file because it has employee records and SSN's.

I'd get hung out to dry if it got out.

I tried editting the file again just now and it seems that changing a character isn't doing the same thing, but adding or deleteing a character makes it work.

I just tried the import on AREV 3.12 and it works. Unfortunately I can't upgrade these guys because it would be a nightmare and I'm sure they wouldn't want to pay for it.

I'm going to see I can get the new import to run on the old system. Doubt it, but what the heck.

From a licensing perspective you probably want them to pay for the upgrade even if they don't USE it.

The Sprezzatura Group

World leaders in all things RevSoft

Doing an upgrade to the latest is pretty much out of the question. Too much software I don't have the source for is one reason and just the amount of time to convert would be prohibitive. I certainly wouldn't do it for free. Plus they are wondering why all of sudden it is doing this. Unfortunately I don't have an answer.

If you have a licensed development copy of 3.12 then you should be able to get the source for IMPORT.ASCII, it was available many moons ago in a developers pack with file REVSOURCE. Ask Rev.

You could then look at it's method of reading the records and compare with yours…..

Last message was assuming you ran Revs ascii import in 3.12

I think Curt is trying to remember the bug which is triggered at byte position 21930 in an OSBREAD or OSBWRITE.

Here is his post about that:

http://www.revelation.com/__85256DB80017688B.nsf/0/8D1FAA2953BF171385256BFE004820C5?Open&Highlight=0,21930

If you can't get there search for 21930 in this forum - there's a lot of postings about it.

This has been fixed and so an upgrade to 3.12 will solve that, if in fact it is the source of your import problem. Otherwise one of the posting will point the way to work around the problem which would require you to write your own import routine, IF this is the problem.

Thanks for the info. I think putting my own import in will be the final fix. I'll search for that number and see if that is where my problem is.

Thanks again

Yeah Thanks. I did run it in 3.12 and it worked and I'm in the process of putting my own import in. I have written a few dozen over the years and I just took a short cut 10 years ago and now it's biting me in the butt.

I doubt this is a problem since 21930 is not a multiple of 1024, and I believe the ASCII import routine reads in blocks of 1024 bytes (I could be wrong).

Sorry if I am offtopic … I was idle for some days … I should agree with Victor

What I would try for A-]B changed files

is

]FC Afile Bfile /b

If exactly one byte is changed … I cannot imagine what happens.

View this thread on the forum...