Hi Mike,

 The exception occurs when openning the file:

Workbook workbook = Infragistics.Excel.Workbook.Load(fileName);

This is working with hundreds of files but with 1 or 2 of them we have a problem. If you like I can email you the excel.

Thanks

Has this issue been fixed in Infragistics3.Excel.v9.2 version 9.2.20092.2106 or Infragistics2.Excel.v10.2 version 10.2.20102.2064?   I've tried my code with both assemblies and still get the Read past end of stream error.

Thanks

It doesn't look like this was fixed as I tried it on 10.1, 10.2, 10.3 with and without the latest service release and it still happens.

The only way to get Workboolk.Load() to open the sreadsheet is to first open it in Excel, then save it.

Infragistics - Please respond to this.

Hi,

I have not heard of any other reports of a problem like this. Can you post a sample project that creates an Excel file that reproduces this problem?

Could this be related to the Excel Workbook being protected by a password. I have tried to open two excel files using:

Infragistics.Excel.

Workbook.Load(txtFilename.Text);

The file that was password protected did not open and I received the error "Attempted to read past the end of the stream..."

The file that was not password protected opened with no problems.

I apologize for the late response, I've been away.

No, the spreadsheet is not password protected.

This situation happens when a client who has an Access 2003 database exports a saved query to an Excel 2003 file. The data is in this spreadsheet is confidential, so I can't post this file directly.

If we open the exported file in Excel and save it as is (with no changes), then the Load() method works.

I also tried this export under Access 2010 with the same behavior: Load() fails with the same exception.

For now, we had to convert to a text file export to get around the issue and we're not using the Infragistics Excel Load() function for this processing.

If there are other users experiencing this issue and Infragistics wants to determine a fix, I can attempt to strip the confidential data out and produce an Excel file that illustrates the issue.

I was actually responding to the previous post by RedRag. I didn't see your post when I posted my reply.

My guess is that there is some feature in your Excel WorkBook that we currently cannot support. But it's certainly possible that there's a bug here that needs to be addressed.

But without being able to duplicate the issue, I can't even begin to guess what that might be. Is there any way you could create a sample Excel file without the proprietary data in it so we can test it out?

Mike -

You misread my earlier reply. I stated:

"No, the spreadsheet is not password protected."

To clarify:

The spreadsheet that we're having this issue with is NOT password protected.