Leaderboard

I had (but lost) some VIs that were knock-offs of the DB Tools List Table and the related Schema VIs. I recreated them fairly quickly this morning. These schema queries return all of a type for a DB, which includes internal. Your tables and views will normally be of a type "dbo". You will have to filter for those in LV. I tried to query my DB for procedures and I did not see a column to filter between system and my own. Google the selected Schema type to get the column names, but most are fairly obvious. If you need to create typdefs for a collection of tables, you can use this scripting VI that I uploaded on the NI Community forums a while back. https://decibel.ni.com/content/docs/DOC-19512 ADO Schema.llb (LV2012)

You can't dismiss the device itself. Some device may have an internal timout to free up resources which means they will actively and willfully drop any connection that has not seen any data transmission for a certain amount of time. While your desktop computer has a sea of memory and CPU power to process many parallel TCP/IP streams at the same time, your embedded device is typically much more resource constrained. They may not even be able to serve more than one endpoint at the same time, so any host trying to connect to them and leaving a connection hanging could block the device for anyone else entirely. That may be a security feature, by locking out other network access while you do some sort of transaction on the device that needs to be uninterrupted by anyone else, but if the device would allow infinite time for a connection to stay open, any misbehaving application could block the device totally for anyone else. So check your documentation! Most likely there is some info as to how long a data connection can stay open inactive before the device will close it from its own side, which is in fact the most common reason for error 66. Another possible reason for this error could be that the device detects some errors while serving the connection, either misformed data packets or some network protocol error due to for instance your bad network card or noisy connection and simply drops a connection on any such error. It is the safest thing to do in network communication: If there is any error during processing of the network connection, close it immediately and let the client reconnect. Your client software should be able to cope with that by using the information returned in the error cluster. Generally a robust network client would treat error 56 as an indication to retry the last operation one or more times (but not indefinitely) and if the error 56 persists or any other error occures, close the connection and attempt to reopen it.

hmm, maybe Jim would love such right-click-menus? :D

If only we had a "ping" function