LabVIEW crashes when reading from MySQL database using NI Database API

[Oksavik]

Yes, I have 4 parent types of plugin, and all other plugins will inherit from one of them, depending on what it does.

The idea was that it would be easy to develop plugins, as long as it followed the "interface" of the parent.

In reality it has been more difficult, but today was a step in the right direction.

Splitting the project files meant I got more separation of the code, and less "dependency-hell". 😉

[wiebe@CARYA]

Thanks.

Good to know those PPLs are an all or nothing kind of thing. Haven't heard that in the presentations, although it might have been implied.

[Mark_Yedinak]

---

wiebe@CARYA wrote:

Thanks.

Good to know those PPLs are an all or nothing kind of thing. Haven't heard that in the presentations, although it might have been implied.

---

THey are and they aren't. It depends on whether you can live with multiple copies of the libraries loaded into memory at one time. It also depends on whether any of the library contain references where you would get multiple copies of an object that was by reference and not by value. In addition, some lower level code such as the DB toolkit rely on external code that is not reentrant so multiple copies of it can cause crashes like the OP experienced.

[Oksavik]

This is my impression as well. There are plenty of code that still is copied into the PPLs, but they don't cause any harm except increasing the size of my application and memory footprint.

I will try to make some changes to the exclude packed / shared libs, as well. What are your recommendations for these settings?

At the moment I'm probably including more than I have to.

I think this is a very interesting design, and with a little practice and experience I think the hassle now will pay off in the long run.