A tough one - Importing a file into a NEW table

[Macsterling]

I work for a company that has a mainframe application that produces "outgoing" files. They are downloaded to a server and converted to ASCII (all at one time) and then ftp'ed to various clients. We are converting to a client server application and I am in charge of verifying that the mainframe application files (converted) are EXACTLY the same as the server application files. I came up with a process of loading the files to access databases and then with a series of queries and reports produce a list of exactly what doesn't match, which record, what positions and display the two fields that are mismatching.

My problem is that when I try to load the Mainframe file (note that it has already been converted and "eyeball to eyeball" the files are alike) using the "new" / import functions, Access rejects the file because it is greater than 65000 bytes. If I cut the file down to under 65k bytes it loads fine. I can load a 500,000 byte file that was created on the server in the first place.

Any suggestions? I can't change any of the processes that create the files. But I can change copies of the files so that I might be able to get them to load so I can verify that the data inside is the same. I'll let the geeks figure out how to fix the file/record control stuff.

(wouldn't have this problem if I was back on a mainframe!!!!)

Mac

 

[FoFa]

Sounds like (just a guess) that the files do not have the proper line end character/s. Open in a hex editor and very there is a CR or CR/LF at the end of each line. Sounds more like you are running into the max string value of 65K

 

[The_Doc_Man]

I second FoFa's surmise - with an addition.

You have to watch out for FTP. It has a hidden 'gotcha' that sometimes kills you flat dead on text-oriented files. Mainframe to mainframe where you are not changing operating system, two files can be FTP'd and work fine. BUT if your mainframe ain't running Windows and you try to import a file from it, you must remember to use TEXT mode (ASCII mode) on the FTP transfer.

What this does is allow the two computers to NEGOTIATE the nature of the transfer so that record size is preserved appropriately on the target computer.

Case in point purely for example: If I get a Windows-created text file via FTP to my OpenVMS box AND I transferred it via BINARY / IMAGE mode, what I get on the OpenVMS side is a continuous data stream with no delimiters between records unless I go back and reset the file characteristics to indicate that some particular control character was used between records. For C files, most often either CR or LF, rarely both. When I transfer using ASCII / TEXT mode, however, the FTP on both sides get involved and send the records one at a time, using the source side file system to split the records and the destination side file system to store the records with the right characteristics. And that is because "image" transfer doesn't know squat about records but "text" mode does.

 

[MStCyr]

It sounds like you are exceeding the MaxLocksPerFile