>Thanks again for the info Sergey - I think you have provided a suggested answer (or at least a link to another thread) for every post I make on here :), but we won't be using any software from that developer that says "beta version" again.
>
>A bit of background on the reason for this and why we have our own code to generate these RecordSets, we started off in late 2001 using the VFPCOM library, early 2002 we found a bug that caused it not to generate certain recordsets if they had a certain number of memo fields or something.
>
>We found that exact library you have pointed to now and it worked great, we thought "it says beta, but it seems to work okay for our purposes" so we could live with the fact it was beta - and then one day towards the end of 2002 a customer rings up and says "why is your program telling us it is beta version now" - this library had decided that after a certain date it would start bringing up a message box stating the fact it was a beta version!!!!
>
>When people put limitations in beta versions they are normally documented, and if he is going to put it up for download on the UT I definately wouldn't expect there to be any limitations such as this, bugs are fine in beta versions and we had thoroughly tested the functionality we were using in his DLL to ensure it worked correctly. We emailed the developer of the library but he refused to provide us with a version without the message box (we even offered full payment) - and I see the library was updated in late 2002 so the messagebox may have been removed, but the download still says beta version so who knows, at the end of this year another message could appear.
>
>So we had to knock up our own code and release a patch for our app to get rid of this library. We also posted here on UT about the bug in VFPCOM and received a response from a MS developer who fixed the bug for us and we beta tested the latest version of VFPCOM for him to ensure it resolved our issue. It did and we have been using that since it was released.
>
>So now we are using our own code to generate the recordsets on Windows 98 and will be sticking with that. The moral of the story is that we won't be using any libraries from the UT download area (or any community site for that matter) that don't include source code ever again, it just can't be trusted in a commercial environment.
>

This is true even for commercial products. I always favor a component or a framework which is "open-source" like every VFP framework for example. If you can't have the source, always try to wrap the component with your own interface so that you can exchange it with another one without having to modify your program everywhere you were using the component.