Empty rows after data get read anyway

[zelite]

Description

I have an excel file with five rows (including headers).
When reading it with the ExcelProvider, I get one extra empty row. Is this the expected behavior?

Repro steps

1. Get the excel file

2. Run the following FSharp script:

#r @"..\packages\ExcelProvider.0.8.1\lib\ExcelProvider.dll"

open FSharp.ExcelProvider

[<Literal>]
let excelFilePath = "TestBook.xlsx"

type ExcelWorkbook = ExcelFile<excelFilePath>

let source = new ExcelWorkbook()

source.Data 
    |> Seq.iter (fun row -> printfn "%A" row)

Expected behavior

I expected the data to only include the rows with actual data on them.

Actual behavior

When printing the rows, I see one extra row which is empty.

Related information

• Windows 7 (x64)
• Excel Provider 0.8.1

[gmlion]

I'm dealing with this bug everytime I use this library. Is this behaviour consistent as it seems? Is there any reason to not cut the last row?

[quintusm]

HI. This seems to be consistent behavior, I am also getting it. I haven't looked in the code as yet to try and see what causes it. The only reason not to remove it is that it may be a breaking change for users who have written code depending on this quirk. It would be interesting to hear from other users how they would want this to be addressed.

[irfancharania]

I would expect this bug to be fixed as a breaking change (and appropriately noted in the release notes).

Currently, I'm doing a quick and dirty work around like this:

    type File = ExcelFile<DefaultFilePath>

    let file = File filePath
    let count = file.Data |> Seq.length

    file.Data
    |> Seq.truncate(count - 1)

[mjdupont]

I think I found and fixed the error in the PR I just put up.

Definitely agree with @quintusm about this breaking behavior relying on it.

If I were reading an auto-generated excel file each day with this, had been using @irfancharania's solution to address the extra line, and updated this library, the change would compile fine, but the resulting code would truncate one row, silently.

I think fixing it and just loudly announcing it as a breaking change makes the most sense. Maybe it would be worth adding an optional parameter to specify if an extra line is included, defaulting to yes, to avoid breaking code relying on this behavior. But then again that's just kicking the can down the road.

It doesn't feel like there's a better answer unless you'd want to be real extreme and force a breaking change, say by requiring a new, dummy parameter on all ExcelProviders. That just seems... quite bad.

[quintusm]

I will work through and merge pull request #41 by @mjdupont and publish a v3 of ExcelProvider noting the fix as a breaking change. I intend to start work on this no later than 11th of September 2024.

[quintusm]

I believe this issue has been resolved in version 3.0.0. which has just been uploaded on NuGet.