Question on my Access Table VI

[roboticstudent]

Hello,

I have attached a code for my table that acquires data using access. 

Does anyone have input on how I can make it better?

I am trying to create a table using LV that acquires and enters data so that novice users can easily manipulate data with LV.

Thanks for all your help in advance.

[mikeporter]

Well the code you have will certainly allow a user to manually edit the values in one table--but then so would opening Access and editing the table in it's tabular views. Which I guess is a long way of saying I don't see what this program will acomplish that other tools can't do better. Plus, in a well-designed database, the ability to interactively modify one table at a time through a spreadsheet-like interface isn't really very useful.

What is the goal of the overall application you're designing?

One big suggestion: lose the database connectivity toolkit. It injects a lot of unnecessary complexity to a process that is basically pretty simple.

Mike...

[roboticstudent]

Hello,

The goal is to be able to access data from machine into LV and then have it transferred automatically into a Access report.  This is a personal project and right now I have only began to just have the LV and Access talking to one another. 

Do you have any suggestions on the above goal.

[roboticstudent]

Hello,

I have attached VI that reflects what I am doing so far.

Please know I am looking for constructive criticism.

If anyone can help, thanks in advance.

[Sheldon_Stokes]

In the interest of not re-inventing the wheel, you may want to have a look at LabSQL:

http://www.jeffreytravis.com/lost/labsql.html

I've played with it for a few minutes and it appears to work as advertised.  I haven't had a chance to use it in my coding.

Sheldon

[mikeporter]

The code basically looks real good. Two suggestions: First, I would make is to move things around a bit so its clearer where things are connected. This sounds minor I know but its no fun spending hours troubleshooting code only to find that a wire isn't connected where you thought it was...

Second, because this is going to be a subvi in something larger, bring out the Error In and Error Out to the front panel/connector pane. You don't want to use NI's error handler in a subvi. You want to bring out your error chain so it can be used to establish a natural data dependency with other subvis in the higher-level application.

Remember error/status data is also data worth managing.

The only other caution is (as I stated in my earlier post) about the use of the toolkit, but if its working for you right now don't worry about it too much. Just know that long-term there are better and cheaper ways of making the connection.

Mike...