DSC VS Database Connectivity

[Nullllll]

welcome

i have project , and i need connect some value with DB .

i have LV 8 , but i dont know what is the best module - DSC (avilabel) or Database Connectivity Toolset( not available )

which i can connect eith DB

[REM1]

QUOTE(Nullllll @ Apr 3 2007, 04:27 PM)

welcome

i have project , and i need connect some value with DB .

i have LV 8 , but i dont know what is the best module - DSC (avilabel) or Database Connectivity Toolset( not available )

which i can connect eith DB

DSC reads/writes to its own database (Citadel - with MSDE for alarm values.) The DBCT connects to other relational databases.

If you are planning on generating some numeric data which you want stored in a database for later retrieval, DSC is an excellent choice although I think more pricey than the DBCT. If you want to read generic data from a relational database like mySQL then DSC is not the right way to go. Since you state that DSC is already available to you I suppose the price issue falls in its favor at the moment.

The thing to remember about logging values using DSC, though, is that Citadel is an NI proprietary database so you will have to use an NI product to get your data back out - though you can export the data for later inport into a spreadsheet.

[xtal]

QUOTE(REM1 @ Apr 3 2007, 08:58 PM)

The thing to remember about logging values using DSC, though, is that Citadel is an NI proprietary database so you will have to use an NI product to get your data back out - though you can export the data for later inport into a spreadsheet.

I thought Citadel had an ODBC interface and any app that can communicate through ODBC (such as the Database Toolkit) could retrieve data from Citadel. Is this not true?

[Yair]

If your needs are simple, you can also find a lot of free and simple solutions where you have to build the SQL query yourself. Try looking at the DB forum here or searching for LabSQL.

BTW, Crystal, since you're already here, I figured you would probably know - I was wondering why the DBCT VIs don't pass the error cluster through a case structure like most VIs and instead always use the helper VIs to build the error. The problem with this is that if a VI accepts an error, it will add its own hierarchy to the source even though it should not even execute.

Is this by design or just an oversight (or some legacy design)?

[xtal]

QUOTE(yen @ Apr 4 2007, 03:04 PM)

Is this by design or just an oversight (or some legacy design)?

I don't know for sure, but I'm guessing it's by design. When I inherited that toolkit, I was told it was finished and I just had to write the docs, release it, and support it. Of course, there were some things that I had to change here and there, but I tried not to change the fundamental design of the toolkit at the last minute. I figured I could always change the error handling a little when I updated the toolkit to the next version.

[REM1]

QUOTE(xtaldaz @ Apr 4 2007, 10:46 AM)

I thought Citadel had an ODBC interface and any app that can communicate through ODBC (such as the Database Toolkit) could retrieve data from Citadel. Is this not true?

You are correct. I failed to mention that. You may beat me when you see me next.

[xtal]

QUOTE(REM1 @ Apr 4 2007, 04:24 PM)

You are correct. I failed to mention that. You may beat me when you see me next.

Cool, more things to look forward to when I return to Austin.

And it looks like I've not gone completely senile yet. Thanks for validating my recollection.