LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Communicating with Access

I am using the Database Connectivity Toolset with LabVIEW 6.1 and
Windows NT 4.0 (SP 6).

Which is better to use, a DSN or a UDL?

Also, the longer my application runs, the more memory and resources it
uses. I have run the same application with logging data to Access
turned on and turned off so I know that the communication to Access is
the guilty party. I need to optimize my data logging. Is there a
better way than the Connectivity Toolset?

Thanks,

Tim Erickson
Signature Control Systems
0 Kudos
Message 1 of 6
(3,138 Views)
TO conserve memory:
1) be sure to close all references that you have to the DB.
2) open ONE connection at the start of the app and reuse it (if it is
appropriate)

Hope this helps!

-Jason Richmond
VI Engineering
LabVIEW Advanced Application Development Course Instructor
Project Engineer II

Tim Erickson wrote:
> I am using the Database Connectivity Toolset with LabVIEW 6.1 and
> Windows NT 4.0 (SP 6).
>
> Which is better to use, a DSN or a UDL?
>
> Also, the longer my application runs, the more memory and resources it
> uses. I have run the same application with logging data to Access
> turned on and turned off so I know that the communication to Access is
> the guilty party. I need to optimize my data logging. Is there a
> better way than the Connectivity Tool
set?
>
> Thanks,
>
> Tim Erickson
> Signature Control Systems
0 Kudos
Message 2 of 6
(3,138 Views)
Is Access running on the same machine?

If so, this may be where the memory issue is coming from.

Access will do what ever it takes to optimze its performance, including eating up as much memory as it can get its hands on.

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 3 of 6
(3,138 Views)
The database is on the same machine but Access is not because it is
not required. I am currently using ODBC.
0 Kudos
Message 4 of 6
(3,138 Views)
There's no guarantee that this is causing your problem, but it's a possibility.

Microsoft had an article that I printed some time ago (can't find the link anymore) titled "Jet 3.0 Dynamic Memory Usage and Access ODBC Driver". Here's a brief transcription:

Quote:
Question:
How does MaxBufferSize setting affect ODBC applications using the Access Driver?

Answer:
Microsoft Access ODBC Driver v3.x is based on Jet 3.0 Engine. If you do not set the MaxBufferSize in the Registry and try to insert records continuously into a table, you will notice a huge growth in the memory consumed by the application (process) using the driver. If your application, running on Windows NT, is inserting records without ever closing the database connection, the system may run out
of virtual memory.

The memory growth will eventually reach a peak value that is equal to the high water mark computed by Jet 3.0 and can be easily mistaken for a memory leak in the driver. However, it is important to note that it is not a memory leak as the memory growth stabilizes after reaching the peak value. This behavior is by design.

If you don't want the driver/Jet to allocate dynamic memory...it is recommended that you set the MaxBufferSize to a value like 512KB....
End quote.

Hope this is of use to you.
0 Kudos
Message 5 of 6
(3,138 Views)
Cool, forget what I said.

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 6
(3,138 Views)