will be writing to database soon and..

[adamrussell]

Boss has been making noises about programming everything to write production
data to databases instead of spreadsheets. I've barely ever even used a
database (and very long ago it was). So can anyone give me advice or point
me to good resources (books or etc)?

[Shan Pin Koh]

I was in your shoes some time ago - not knowing the most effective way for working with a database. The only database class that I took was dBase III and that was about 10 years ago.

I used MS Access 2000 for database. It is very straight forward. What would be interesting is the way you extract the data. You can use Access to generate your queries and later get the corresponding SQL commands.

For that, I would suggest that you get a book on SQL. I bought, "Teach Yourself SQL by Stephens and Plew (SAMS)". Next, you would need to get a SQL Toolkit from NI if you were to do SQL.

Alternatively, you can use Active X, if you're familiar with it and communicate with your database.

This is assuming that you're on the Windows environment.

Hope that helps.

Shan Pin Ko
h

[Dennis_Knutson]

The first thing I would recomend is to buy the Database Connectivity Toolkit. This would give you the most flexibility and ease of use (assuming Windows platform). The actual database back end will depend on what you want to do with it. In my experience, Access is only good for a limited number of users. When we had 2 test stations recording data, we only had conflicts occasionally. With 4, we'd have a conflict at least once a week. With 6, we'd have daily problems. At that point we installed Microsoft's SQL Server. We're now up to about 50 test stations and the only time we have a problem is when someone runs a query with MS Access as the front end. Oracle is another good database for multiple users.

[DavidBoyd]

Dennis, I agree with you about using the DB Connectivity Toolkit - though I've only worked with a beta copy, it looks like a worthwhile purchase for the original poster. I've extensively used the SQL toolkit (DB Tools' predecessor). I would say the OP must get a good book on relational DB design before starting - toolkits are no substitute for good table design. I'm surprised at your comment, though, about Access not scaling well - I've had a built LV app using the SQL toolkit/ODBC/Access '97 running on four test stations for the past eight months, where the .mdb file is on a network share, and each station INSERTs a test record approx every 40 seconds, plus operator actions cause SELECTs, INSERTS, etc. at random times, plus people (like me) do Access que
ries from desktops, and the stations run solid as a rock. Two stns running under W95, two running W2K, all on LAN. Wouldn't want to try 50 stns, though, but 4 to 8 should be a breeze.

To OP: Get Rebecca Riordan's 'Designing Relational Databases' (sorry, it's @ work, that may not be precise title) from Microsoft Press, esp. if you're considering Access or SQL Server. **Learn what good RDB design is before collecting data ** - I can't stress that enough. Best of luck!

[Dennis_Knutson]

I was surprised by the scaling problem myself. All of my database write activity is done by NI's TestStand with custom queries/reports done in Access. The problem (as explained to me by our database administrator) is that Access does page locking whereas SQL Server does record locking. Adjusting the ODBC timeout helped but eventually it got so long as to be ridiculous.

I totally agree with you about database design. In my case, a few hours spent with a database expert saved a ton of grief later on.