jpc

QUOTE(xtaldaz @ Nov 26 2007, 05:08 PM) We are using MS SQL Server 2003, and MS SQL Server ODBC Driver Version 2000.85.1117.0 according to the ODBC Data Source Administrator Drivers tab. When I set up the ODBC connection and run the connectivity test, it lists the driver version as 03.85.1117. The strings are going to be specific to the ODBC connection you make and the database you use, so I made them string controls in the demo VI. The ODBC Data Source Name was created in the System DSN tab of the ODBC Data Source Administrator. I tried the test on both my WinXP desktop, a constantly updated domain machine, and a minimal WinXP SP2 install running as an embedded workgroup computer, and the results are the same. Let me know if there's anything else I've forgotten to mention. It would be great to get confirmation from someone else before I report anything to NI. -John

I decided to dig into this problem a little deeper to see if I could find the source of the memory leak. I discovered that opening and closing the ODBC connection alone does not generate a leak. The leak did not occur until I inserted a table read in between the open close. I thought this was odd, because the error cluster generated on the failed open should pass through the read VI aborting its execution. However within the read VI (DB Tools Select Data.vi) is a subVI called DB Tools Error Helper.vi that is executed regardless of whether an error is passed in or not. The memory leak is occurring in this Error Helper VI when processing an error. I am attaching the test program VI I used with Windows XP SP2, Labview V7.1, and the Database Connectivity Toolkit, which to my understanding has not changed through several Labview revisions. After setting up an ODBC connection to a SQL test database, I run the program and make sure the table can be read with no errors. To check the memory usage, I run the Task Manager and monitor the Commit Charge value. To simulate a server crash, I unplug the network connection. The Commit Charge value initially jumps, then stabilizes, as the ODBC breaks and the error is realized and displayed. With the switch set to skip the DB Tools Select Data.VI when an error occurs, there is no growth to the Commit Charge memory value. Toggle the switch to allow the error cluster to pass through the Select Data.VI and the memory grows by 4K per loop iteration. To confirm the leak in the Error Helper.VI, I commented out its use in the DB Tools Select Data.VI (see the 2nd attachment) and reran the test. No memory growth. I didn't dig any deeper into the Error Helper.VI to find the error source. It does call the "Call Chain" Labview primitive to get a list of all the VIs for reporting errors, perhaps it's in there. The Error Helper.VI is called by quite a few other VIs in the Toolkit, but not the open and close connection VIs, which explains why my initial test results seemed odd (and probably a lot of other things too). Since our app is running on embedded PCs, commenting out a display routine will serve as a workaround until a fixed version of the Database Connectivity Toolkit comes out. I hope this helps those who have been frustrated with this problem. -John

I decided to dig into this problem a little deeper to see if I could find the source of the memory leak. I discovered that opening and closing the ODBC connection alone does not generate a leak. The leak did not occur until I inserted a table read in between the open close. I thought this was odd, because the error cluster generated on the failed open should pass through the read VI aborting its execution. However within the read VI (DB Tools Select Data.vi) is a subVI called DB Tools Error Helper.vi that is executed regardless of whether an error is passed in or not. The memory leak is occurring in this Error Helper VI when processing an error. I am attaching the test program VI I used with Windows XP SP2, Labview V7.1, and the Database Connectivity Toolkit, which to my understanding has not changed through several Labview revisions. After setting up an ODBC connection to a SQL test database, I run the program and make sure the table can be read with no errors. To check the memory usage, I run the Task Manager and monitor the Commit Charge value. To simulate a server crash, I unplug the network connection. The Commit Charge value initially jumps, then stabilizes, as the ODBC breaks and the error is realized and displayed. With the switch set to skip the DB Tools Select Data.VI when an error occurs, there is no growth to the Commit Charge memory value. Toggle the switch to allow the error cluster to pass through the Select Data.VI and the memory grows by 4K per loop iteration. To confirm the leak in the Error Helper.VI, I commented out its use in the DB Tools Select Data.VI (see the 2nd attachment) and reran the test. No memory growth. I didn't dig any deeper into the Error Helper.VI to find the error source. It does call the "Call Chain" Labview primitive to get a list of all the VIs for reporting errors, perhaps it's in there. The Error Helper.VI is called by quite a few other VIs in the Toolkit, but not the open and close connection VIs, which explains why my initial test results seemed odd (and probably a lot of other things too). Since our app is running on embedded PCs, commenting out a display routine will serve as a workaround until a fixed version of the Database Connectivity Toolkit comes out. I hope this helps those who have been frustrated with this problem. -John

We are experiencing what we believe is a memory leak in Labview 7.1 when attempting to open and reopen an ODBC connection to a SQL database. I have seen this topic mentioned in several places... http://forums.lavag.org/Memory-Leak-t9438.html http://forums.lavag.org/Memory-usage-issue...lkit-t6570.html http://forums.ni.com/ni/board/message?boar...essage.id=53391 ...but, the problem resolution seems to be to just open and close the connection once. OK, you lose 4K of memory and no big deal. But in our case, we have a control system reading and writing to a SQL database at regular intervals, and would like to re-establish that connection automatically if it becomes broken (server crash, maintenance, backups, etc.). So the app was designed to loop every few seconds trying to reconnect. We wrote the code, it works well unless the server is down for extended periods of time. Then we noticed the app crashes from depleted memory. We isolated the problem to an open/close connection problem just like in the links above. So my questions are: Has this been confirmed to be a Labview problem? Or is it a ODBC problem with SQL? Does anyone know if NI has ever addressed this issue? And, yes, we have a workaround in place. The error is flagged and an operator must manually reconnect when the server is determined to be back online. We cannot risk crashing the control system. We would like to go back to the automatic reconnect, but I still haven't seen this memory leak problem resolved. My colleague who wrote code claims Labview 8.5 still has not fixed this problem. -John

Yes, that article is actually what got me started down this path, but what it does not mention is what agent (.exe?) is used to act on the entries when a change is made. I know that when the registry is changed by changing options in Control Panel/System/Automatic Updates, the "wuauclt" process is started to monitor and control the updates. But I was not able to start that process manually. I also know that changing the entries without that process running produces no change. I am hoping that changing entries that control scheduling with the "wuauclt" process running will accomplish the delay I'm looking for.

Hi, I'm looking for a method to control the scheduling of automatic download and installation of Windows Updates such that they do not occur until enabled. I would like to turn the "automatic updates" feature on (in Win2K & WinXP) and leave it on, but have the ability to hold off the automatic DL and install until the LV program decides it is safe to do so. It would be acceptable, and desirable, to have the "Your updates are ready to install" balloon pop up and be confirmed by the operator. My best lead at this point is that the scheduling appears to be done by registry entries at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update, but I'm not sure it's as obvious as it first appears. So...I wondering if anyone has tried this, has sample code, or a better method ? For that matter, it would great to do the same for virus scanners, defragmenters, etc. ...or am I dreaming? -John