Re: [foxboro] client server

Jeremy,
        Thanks for jumping in with your reply to Corey.  You made some
of the points I thought about sending but hadn't done yet.  I said in
one of my earliest posts on this subject that I think SQL databases
coupled with internet browsers are a potential unifying architecture
between disparate operating systems and applications.  When thinking of
communicating DCS based data to a wider audience than just the control
system users, the power and adaptability of using SQL databases becomes
more apparent.
        SQL databases have been around since the early 70's. Offerings
like Oracle, SYBASE, PostgreSQL, FoxPro, MySQL, Paradox, Interbase, SQL
Server, IBM DB2, and MS Access allow the user to run one on virtually
any OS.  SQL means Structured Query Language, and there are basic query
language commands adhered to by all of these that make them capable of
being queried cross platform.  To be sure, most of these offerings
decided to include extended commands that differentiate their product
but also make them proprietary and limit the extended function
usefulness in cross platform environments.  Microsoft is the most
notorious of the bunch, but the basics of SQL are still useable.
        My previous example of how EBAY can provide data on millions of
items for sale in virtual real time to my browser attempted to convey
the power and speed that SQL databases coupled with browsers as the HMI
can enable.  For cross-platform browser viewing capabilities the
standard canned query forms are stored on the host server so that all
users use the same query format and the server performs the query, on
platform, and returns the results as a served web page to browsers
running on any platform.
        My interests in an SQL database reporting format for the DCS
data are associated with how I already see our corporation sharing data.
Our SAP Servers run in a Solaris environment, our corporate network is
mostly managed and viewed from an MS platform, our control systems are a
mix of both.  Data is required in a global fashion as input to SAP.
Applications spread throughout the corporation are using data from SAP
for additional decision making.  Applications such as INTools that we
use for instrument documentation have strong relationships with control
system data. OSI PI and the DCS contain relational information also and
we have started to share some data.  Basically, the easier it is to get
the data from one app to the next, the more valuable, and consistent,
the data will become.
        Daisy-chaining data and re-launching the same data from
different places erodes the understanding and complicates
troubleshooting.  Checkpoint, workfiles, .O object files, and CSA
database files compared to the memory in a CP are an example of this.
One source/server, unlimited "secure" clients throughout the world, and
a universal HMI to view the data is now a potentially achievable design
goal.  The companies that exist solely as internet marketers or as
internet data sources figured this out quite awhile ago.  Commodity
Manufacturing Companies are being forced, often unwillingly, to follow
in their footsteps, to remain competitive.  SQL databases are one of the
essential building blocks used today to make it all possible. =20
        I remember when all of this sounded like a bunch of "pie in the
sky" "mumbo jumbo" and was the farthest thing from my mind.  After all
"I'm just a DCS guy". Many of you may still feel that way, but things
will change, with or without your approval and it might become important
to you.  I think SQL databases will then be important to you. (Stepping
down from stump)

Cheers,
Tom VandeWater
Control Systems Developer/Analyst
Dow Corning Corporation
Carrollton, KY   USA

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Jeremy Milum
Sent: Thursday, March 29, 2007 9:14 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] client server

On 3/28/07, Corey R Clingo <corey.clingo@xxxxxxxx> wrote:
> SQL sounds good on paper, but if it is M$ SQL Server, and I'm running
a
> processing script on a Unix box (AW51 or something else), how do I get
to
> it?  Maybe there are Unix ODBC drivers for SQL Server, but it can't be
> common.

I don't think ODBC would be necessary. I am far from a proponent of
M$, but SQL is a standard (albeit every db has proprietary additions,
but you aren't required to use them). Just because the data would be
in M$ SQL Server, does not mean that it would be any harder to get out
than it is now. SQL Server has a command line query program. A SQL
script could be saved in a text file and run with the command line
utility. That would be easily scriptable from UNIX. Much in the same
way that no one needs to know the ICC commands to run the iccprt
script. I doubt ANY method they come up with for getting data out if
the IEE will be directly usable on the UNIX boxes, something will no
doubt have to be run on the windows machines. Why not have the power
of SQL if you want it? A SQL script could be used to export the data
as flat ascii delimited text, or even XML. So EVERYONE could have what
they want.

Perhaps I am biased as I think SQL rocks, but I see it as the generic
solution that provides the most power and flexibility. Want to know
where a block is used then run a simple query, rather than 1) export
to XML, 2) write a parser, 3) read in the exported file, 4) scan the
XML for your answer (which is not trivial). All that could be done in
one step.

But as I have said before, a SQL solution will provide all the other
formats too. Why limit it to one of the others?
=20
=20
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
=20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe:      =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=20
 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: