Re: [foxboro] client server

Re: I haven't used it yet, but from what I see right now (after looking
at IACC), those tools seem to be answers to a question that I never
asked.

Is that because the question you want answered has to do with reporting
on and querying control schemes versus creation of control schemes?

Regards,
 =

Alex Johnson
Invensys Systems, Inc.
10900 Equity Drive
Houston, TX 77041
713.329.8472 (voice)
713.329.1700 (fax)
713.329.1600 (switchboard)
alex.johnson@xxxxxxxxxxxxxxxx

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Corey R Clingo
Sent: Thursday, March 29, 2007 12:54 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] client server

Assuming one could rig up a remote command execution facility on a =

Foxboro-supplied Windows box without trouble, you would be correct; I =

could get to it.  But then it is little different than running a =

Foxboro-supplied utility to get the data.  You may have more query =

flexibility with SQL, but I guess I envision dumping all the data out
and =

putting it into a database/schema of my choosing anyway, so that =

flexibility does not really buy me anything.  Others of course may feel =

different.

And maybe this mindset is also one of the things that makes me favor
using =

the checkpoint as the primary DB, with auxiliary information as
required. =

It sounds like Invensys is doing this some with IEE (i.e., SQL server
plus =

some object data), though not utilizing the checkpoint is unfortunate.
It =

is probably also why I am not so excited about or concerned with =

IACC/IEE/day-after-tomorrow's configuration tool.  I haven't used it
yet, =

but from what I see right now (after looking at IACC), those tools seem
to =

be answers to a question that I never asked.


Corey Clingo
BASF Corporation






"Jeremy Milum" <jmilum@xxxxxxxxx> =

Sent by: foxboro-bounce@xxxxxxxxxxxxx
03/29/2007 08:14 AM
Please respond to
foxboro@xxxxxxxxxxxxx


To
foxboro@xxxxxxxxxxxxx
cc

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?




 =

 =

_______________________________________________________________________
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=3Djoin
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
 =




Confidentiality Notice:
The information contained in this electronic message and any attachment(s) =
to this message are intended for the exclusive use of the recipient(s) and =
may contain confidential, privileged or proprietary information. If you are=
 not the intended recipient, please notify the sender immediately, delete a=
ll copies of this message and any attachment(s). Any other use of the E-Mai=
l by you is prohibited.


 
 
_______________________________________________________________________
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: