@wanderson
I also wanted to speak to your concern about accessing databases. You absolutely can access databases without the database connectivity toolkit. And while database access is easier with the toolkit, it can still be done otherwise, and done quite well, depending on how much time you care to dedicate to the task.
Its a lot like the report generation toolkit. The report generation toolkit contains a lot of useful templates already created for reporting in various formats, docx, xml, xlsx, etc. However, you can do reporting creating your own template without the toolkit.
These toolkits have come into existence based on the idea that usually LabVIEW programming is done by a hired hand or consultant, such as myself. These consultants are expensive in terms of hourly rate, and so the cost of toolkit vs many hours of consulting rate to format your own is really the question.
Another great example is TestStand, which I personally recommend anyone doing test sequencing to purchase. Yes, I can and have written my own sequencers for testing, but the package is a grand or two and makes your sequences such that they jive with all of the other test sequencing in the test industry. Nevermind that all of the debugging and headaches I have to sort through to employ a custom sequencer will run up a billing rate far exceeding the cost of TestStand, but keeping your development on the ‘beaten path’ is highly advisable since a developer can leverage most if not all of the parts and pieces needed. Venture out on your own, yes you can think you are saving somethinig, but in all honesty, you will pay a lot more in development being out there all on your own.
And I would also like to speak to the concept of LabVIEW being only for a niche market. Sure, I can go for that. That niche market is computerized measurement and automation, which is not such a small niche. In fact, all tech businesses do this to varying degrees, and NI has become THE name in this area. As stated before 1 in 200 programs written on planet earth are LabVIEW programs, with LabVIEW programmers numbering over 1 million worldwide. I have noticed acceptance of this programming style to be well accepted in the product test and development world, computerized instrumentation markets, and prototyping world (my interest at DMS). Since I can do rapid development/rapid deployment in this language, its a great choice to start out most designs. Once volumes begin to ramp and cost savings becomes important, it makes sense to perahps look at converting the tried an tested code into firmware that can run on smaller, cheaper architectures. But no point in paying this engineering cost until it becomes clear it is warranted.
Anyhow, I hope this helps makes it clear why I keep hammering LabVIEW at all these possible nails. Its quick, its easy, its cheap in terms of up front development time. But this in no way discounts the use of other languages, each of which have their respective places in our growing tech capabilities palette.