WPF Export PDF leaves mdb lock file

[khopcuseti]

I am using the CrystalReportsRunner in a dotnet core WPF app and everything is working great except I can't figure out why when the report PDF is generated that datasource mdb lock file is still present. If I open the mdb file directly and close it then the lock file goes away. I have isolated it to this process the instanc eis being disposed of correcectly so I am not sure why this is happening? Reading and writing to the file works like it is supposed to. Any insight?

[gerardo-lijs]

I honestly never tried it with an mdb as datasource. I can give it a go and see if by adding some Close/Dispose or changing something in the datasource connection parameters it solves this.

1. Can you provide me a sample mdb so I can add some Unit Tests for this scenario? I could create a simple one, but best to use some test mdb that we know for sure it fails

2. How are you checking the lock is removed or left behind? Again, I could try some approaches, but even better to try it in the same way you are using it.

3. Finally, can you provide the sample code you are using to report this mdb file? Mainly I'm interested in how you are setting up the Report Connection since we only have builders for SQL. Check this link: https://github.com/gerardo-lijs/CrystalReportsRunner/blob/main/src/LijsDev.CrystalReportsRunner.Core/CrystalReportsConnectionFactory.cs

You might be able to fix it by changing the connection parameters

[khopcuseti]

The process I am using is to populate the mdb file with the data from another process I am using, then calling the runner to generate the pdf using a crystal report (which has connections to the mdb) to a folder. I watch the folder the mdb file is in as it is going through the population of data and then the report generation.

At first, I thought maybe it was the connections I was using, but then Isolated both processes and ran them each separately and it didn't happen on populating the mdb file with data. I also can open the crystal report, preview it (lock file is generated), and then close the report, and the lock file is removed.

I have attached the mdb file, as well as the code file and crystal report.
ReportingQC.zip

[gerardo-lijs]

A took a look at the code during lunch break today and it seems that using our library for this might not be the best approach. I understand your main app is .NET Core and you need to click a button (or something else) to fire this report generation.

What I did was create a simple app in .NET Framework 4.8 that you can call from your caller .NET Core app. This would avoid the namedpipes, serialization and all the extra stuff that goes around in this library.

It worked perfectly and not leaving any lock for access file!

It is just using the Cystal Reports Runtime v13.0.20 32bits (but you can change and use whatever version you are currently using to avoid extra installations). Right now its using the connection information stored in the RPT file and in the computer ODBC. This could be also configured programatically but it will require a little bit of testing to get it right.

I left a few TODOs in the code. Feel free to contact me via Twitter or at my email [email protected] if you like this approach and I won't mind finishing it after making sure I got the requirements rights. All this testing/development really took me less than two hours so its a not a big deal and always nice to help other developers. It was also a nice memory throwback to 20+ years ago when I had to deal with Access at the start of my career!

CrystalReportsExportCLI.zip

[khopcuseti]

Thanks!!! I'll try it out and let you know how it works.