Re: [foxboro] client server

It's been tough keeping up with this thread while digging out of my own
pile of tasks. Just a lot of data to absorb. However, I picked up on
Tom's point here: SQL the methodology as opposed to SQL the "M$ Server".
SQL the method is the best way to go. I've integrated a number of
business and process applications including those written in Foxpro,
Dbase, Access, Goldmine, Quickbooks, Excel and 123. As long as there is
a native driver or an ODBC driver, I can get the data using SQL. I
personally like Access as the "glue" between the databases because of
the easy drag-and-drop query builder. I even use Access to construct SQL
queries (cut and paste the SQL into the code) for my web-based data
displays. So you don't even have to be using M$ Jet as an engine to
drive your queries, any old SQL API will do. 


Best Regards, 
Ken Heywood 
Process Control Services, Inc.


-----Original Message-----
From: tom.vandewater@xxxxxxxxxxxxxx
[mailto:tom.vandewater@xxxxxxxxxxxxxx] 
Sent: Thursday, March 29, 2007 1:35 PM
To: foxboro@xxxxxxxxxxxxx
Subject: 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
 
 
--------------------------------------------------------

 
This message (and any associated files) is intended only for the 
use of the individual or entity to which it is addressed and may 
contain information that is CONFIDENTIAL, subject to copyright or
constitutes a trade secret. If you are not the intended recipient 
you are hereby notified that any dissemination, copying or 
distribution of this message, or files associated with this message, 
is strictly prohibited. If you have received this message in error, 
please notify us immediately by replying to the message and deleting 
it from your computer. Messages sent to and from PCS may be monitored. 

Internet communications cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, arrive 
late or incomplete, or contain viruses. Therefore, we do not accept 
responsibility for any errors or omissions that are present in this 
message, or any attachment, that have arisen as a result of e-mail 
transmission. If verification is required, please request a hard-copy 
version. Any views or opinions presented are solely those of the author 
and do not necessarily represent those of the company.
 
 
_______________________________________________________________________
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: