On Mon, 2004-12-06 at 13:28, Chuck Hast wrote:
> The present application writes the data to a flat file. The guy who does
> the app is going re-work the app so that it can write directly to a db
> using ODBC or probably JDBC, as he is looking at re-writing in Java
> so that we are not chained to the windows environment.
Ack! ODBC? Ouch! Overhead, Overhead Will Robinson! ;->
I don't know what your data-rate is, so maybe ODBC (or JDBC) is doable.
I'm not a fan of "middle-ware" when it comes to read-time DAQ. But I
don't know your data-rate in your DAQ.
> I will have a ODBC or JDBC connection to a db ... We want to have the
> app just dump it directly into the db and be done with it,
Right. Again, I'd need to know what data-rates we are talking.
> at the same time while driving down the road we will have one or more
> mapping machines to use to look at the data, there are preset levels
> that will either show a obnoxious color or a strange symbol when some
> level or other data is off.
Now that might change some things depending on how "real-time" you want
it. If a 10+ second delay is an option, then a DB is fine.
> Perhaps it would be good for me to send you a sample db and some
> map images so you can see what we are doing.
Maybe. But that's all off-line. I'm trying to figure out how much is
coming in real-time.
The issue with DAQ is ensuring that you get all of it. Acquisition is
the most important, first step. If the rate is low enough, then about
98% of what I said doesn't apply, and I'm just being anal. ;->
> Yes, that must be fun to watch, any mass destruction is fun to watch.
> Imploded buildings, vehicles, of course as long as there is no loss of
> life involved.
Doesn't compare to seeing Mach 3-5 hit Mach 5+. ;->
> Basicly the data will enter via odbc/jdbc and exit the same way. We
> pull the data into the mapping tools and create nice maps of the different
> data fields. Right now we are doing it with Access and Oracle, on Windows
> as soon as my cohort in crime re-does the app to where it uses the odbc
> drivers we will deposit it directly to a db.
Oh, so you don't have the data rates I was thinking of. Nevermind.
> I am just trying to pick the right one from the start for the mobile piece,
> once we get it back to the office it will probably be exported to something
> else depending on what the customer wants it in.
Once you get it in the DB, then it's read-only, correct?
MySQL or PostgreSQL will do fine.
Both have ODBC and JDBC connectors.
> c. Want to use Linux as I feel it is a much more stable environment than windows
> I have had windows do too many strange things while doing the capture.
> have even had viruses come down the pipe, and we had all of the virus stuff
> on the machines.
I look at ODBC as a _nightmare_ -- especially when Access (especially
with Jet) is involved.
Oracle is a fine solution. In fact, if you're already using Oracle as
your back-end, I'd stick with it. You've got some of the work already
done for you, and already have it in place.
Just don't involve Access. ;->
JDBC will do fine then.
> Yes, but I will be handing the db off to others who will then put it
> in whatever they want.
At that point, then we're no longer talking DAQ.
Again, I was probably just being "anal." You don't sound like you have
the data-rates I was thinking.
Although we might want to revisit it for the real-time monitoring if you
can't afford delays. But it doesn't sound like it.
-- Bryan J. Smith b.j.smith@ieee.org ------------------------------------------------------------------ Beware of advocates who justify their preference not in terms of what they like about their "choice," but what they did not like about another option. Such advocacy is more hurtful than helpful.----------------------------------------------------------------------- This list is provided as an unmoderated internet service by Networked Knowledge Systems (NKS). Views and opinions expressed in messages posted are those of the author and do not necessarily reflect the official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:35:13 EDT