Appreciate the feedback. Yeah, that was my take on it as well - ADO.NET should be ADO.NET. However, after a few decades of dealing with MS technologies, I never take that as gospel.
When I get some time I'm going to try it again as the performance difference is significant, but I eyeballed the code pretty intensely and am as sure as I ever am about such things that it was the same in both environments. I hope to be wrong about that because otherwise I'm out of ideas.
That's a nice approach. The DataTable was from an example I found on TVPs. I was focused on making the db interaction worked and never thought to convert it to something more elegant. Deadlines and all that.
I'm going to take another swing at this today. Hopefully I just fat fingered something when I cloned the MVC code I was using. Appreciate all the help.
Well, apparently the fingers are indeed fat. Tried again this morning and it worked without a fuss.
Still using DataTable approach at this point. MS says SqlDataRecord is resource abusive and recommends not creating a new one but reusing a single instance. That aside, are there any benefits to the enumerable approach over populating a data table?
We have some code which receives images of a document from a C++ DLL, and displays them in a WPF application. The C# code stores the images in an array, which it flushes each time a new document is placed on the scanner. The code converts the image from a Bitmap to a BitmapImage, which is the image type for display in WPF:
Are all machines running exactly the same version of .Net?
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
As previously suggested, check the .NET versions on the machines; there have been a few issues that vary by version.
I would probably try moving the creation of the BitmapImage outside of the using block, or try some garbage collection routines, or object disposal to see what kind of response you get from what methods
Director of Transmogrification Services
Shinobi of Query Language
Master of Yoda Conditional
Thank you to everyone for your thoughts. It appears to be unrelated to the version of .Net.
I found the source for MemoryStream and the Dispose method does NOT set the buffer reference to null. I tried assigning a static buffer to the MemoryStream instance instead of allowing it to allocate its own buffer but that caused a crash.
I created test WPF and WinForms apps and the results are bizarre.
We have a small C# class - VideoOCRWrapper - which drives an attached OCR document scanner. It essentially makes calls to a C++ DLL, and has a callback which receives a IntPtr containing a HWND. On receipt of a bitmap, it converts it to a BitmapImage and fires an event to provide a client with the BitmapImage isntance.
I created a WinForms app, which initialises VideoOCRWrapper and displays the received bitmap. It has converts the BitmapImage to a Bitmap for display.It shows no memory leaks.
I created a WPF app, which initialises VideoOCRWrapper and displays the received bitmap. It shows a huge memory leak consistent with the bitmap buffer leaking.
The two apps use almost the same code, except that the WinForms overrides the form's WndProc, whereas the WPF app hooks its own WndProc onto the main window.
I memory profiled the WPF test app, and it said that "22 types have instances that are queued for finalization. This can indicate that a Finalizer method is stuck, which will prevent instances from being finalized and cause memory leaks.".
There is an extra factor. We use a third party DLL for document verification, which receives bitmaps from us. If I remove that DLL, our code shows no leaks. If I add that DLL, we have leaks but only when running our WPF test app, or our WPF application. When running the WinForms test app, we have no leaks.
I am working on a WPF application handling lists too long to fit in the window, so it needs a scroll bar. But elements of the list (a vertical stack panel) may flash up indicators that preferably should be acted on without too much delay; they should not be outside the window.
So I imagine a modified scrollbar mechanisms: A certain fraction of the contents is displayed in normal size (or even normal++, for those of us who are not as young as we used to be). Lines above or below this area is gradually reduced in size, so that more of them would fit above/below the "reading zone" of the window (with the attention indicators visible), without scrolling out. The reading zone would be somewhat like a cylinder lens, except with a central flat area of constant magnification.
Preferably, the size falloff outside the reading zone should be configurable, as well as the fraction of the window making up the reading zone. It would also be nice if it could be applied to columns of a table one-by-one, so that the columns remain straight from top to bottom, even though the cell contents is reduced in size.
I tried to google for 'cylinder lens scrollbar', without much success. Has anyone around here seen such a scrolling mechanism? Do you have hits for other google terms? Or should I just sit down and start implementing it myself?
(I suspect that my implmentation would be too much tailored to my specific needs at the moment; if there is anything like this out in the wild, it is probably of far more general use!)