Re: [foxboro] client server

Re: Some IEE data IS stored in an SQL database, but not one that has the
traditional row and column structure we are used to seeing in
spreadsheets/table databases?

All IEE data is stored in the SQL Server database.

Its schema is such that you cannot query the data of interest using SQL
queries.

The schema stores strategies (a collection of blocks) not blocks as the
entities that are visible through SQL queries.


Re: Is ALL IEE data stored in an SQL database?
Yes.


Re: If not, is the remainder of the data defined in XML format?
None is stored as XML data. Such a storage mechanism would be pretty
inefficient since XML is basically an annotated ASCII file.


Re: Are the Strategy Objects you mentioned actually in XML format?
The are not stored as XML internally, but they could be exported as XML.


Re: Like Ted Jirik mentions, Are Strategy Objects and things like PLB
and sequence code stored in the SQL database as BLOBS, ("Binary Large
Objects"?
Yes.

Re: If we "voted" for an SQL report format would the IEE data be
presented in tables that have a more traditional data structure for the
Compounds, Blocks, and parameters?

If we decided to export the data to a set of SQL Server tables in an
"export database", I would expect it to be a set of tables for things
like blocks, schemas, CPs, etc. that are properly linked with keys so
that the expected searches could be performed.


Re: I could be persuaded to vote XML if it provides more complete data
presentation/reporting capabilities and doesn't require that I become an
XML expert to use it.

XML exports are ASCII files that can be manipulated using tools that can
be found in various locations.

I doubt that we would do much more than export it if we choose to export
in XML.


Re: Why I'm asking these questions of the list
I expect to have a reporting facility that supports some queries, but
may be not the ones you really want. The idea of the export is to allow
the user to build tools above and beyond what we offer for reporting. =


The goal is to see what the best auxiliary format would be.


Does that make sense?


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 tom.vandewater@xxxxxxxxxxxxxx
Sent: Tuesday, March 27, 2007 9:07 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] client server

Alex,
        Hang in there with me as I am learning a lot but might ask
questions that show my a-- / lack of understanding about the
technologies employed.  I know we are talking about the reporting
mechanism to use to export information to users but my "vote" is
influenced by where and how the data is stored for Foxboro/Wonderware
use.  I have jotted down a list of what I "think" I understand and you
can correct me when I am wrong.  I think we are boiling it down for more
than just the people actively participating in this thread so there
should be more value than my own satisfaction of grasping the
complexities of this topic.

Some IEE data IS stored in an SQL database, but not one that has the
traditional row and column structure we are used to seeing in
spreadsheets/table databases?

Is ALL IEE data stored in an SQL database?

If not, is the remainder of the data defined in XML format?

Are the Strategy Objects you mentioned actually in XML format?

Like Ted Jirik mentions, Are Strategy Objects and things like PLB and
sequence code stored in the SQL database as BLOBS, ("Binary Large
Objects"?

To understand the nature of database BLOBS I found this link very
useful.
http://www.faqts.com/knowledge_base/view.phtml/aid/416

If we "voted" for an SQL report format would the IEE data be presented
in tables that have a more traditional data structure for the Compounds,
Blocks, and parameters?

I think I understand Dave Johnson and Ted Jirik's reasons for voting for
XML.  There are pieces to the IEE data that don't lend themselves to be
easily stored or found in a tabular database structure.  Sequence code,
ladder logic, and possibly the Strategy Objects that you refer to, could
be stored in an SQL database as BLOBS but that might make them less
queriable / accessible than XML.

I could be persuaded to vote XML if it provides more complete data
presentation/reporting capabilities and doesn't require that I become an
XML expert to use it.

Thanks for any additional insights from anyone involved in this thread.
Cheers,
Tom VandeWater

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Johnson, Alex P (IPS)
Sent: Monday, March 26, 2007 4:41 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] client server

Re: Is the IEE data stored in an SQL database?

Yes, but the block data is embedded in a Strategy object and is not
accessible by normal SQL queries. That is, the block data is not stored
in rows and columns in tables. =3D3D



Re: Is XML being used to retrieve data from the SQL database and then
recreate XML data fields for an HMI display that can be browser based?

I don't understand the question.

With regard to HMIs, we offer two GUIs - FoxView and InFusion View
(InTouch plus an InTouch application we created to make it somewhat
easier to use). Neither GUI is browser based. Neither GUI uses XML to
any significant degree.

With regard to "data from the SQL database", as you might expect after
the last comment, there is no data in the database that is used to drive
an XML based GUI.



Re: XML
XML is a data description language. Think ASCII files with descriptors
and you are there. Actually, it's really similar in intent to the old
Word*Star word processing documents. If you remember, it used control
codes embedded in the ASCII text of a document to control the formatting
of the text. Change their control codes to XLM key words and you are
there.

[I'm old. XML with SOAP looks a lot like ASCII files and FTP to me.]

XML is a reasonable format for presenting control block data and there
are tools that can help one write scripts to process that data and
present it.

Does this help?


Regards,
 =3D3D

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 tom.vandewater@xxxxxxxxxxxxxx
Sent: Monday, March 26, 2007 3:20 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] client server

Alex,
        That was brief enough to make me ask questions :<)

Is the IEE data stored in an SQL database?

Is XML being used to retrieve data from the SQL database and then
recreate XML data fields for an HMI display that can be browser based?

 I have to admit that my understanding of XML is weak and caused me to
google it to try and clear up my lack of experience with it.  It sounds
like its strength is not as a data storage repository for all the data
but more as a user interface tool that incorporates data in a database
and replicates it as data that it can define and export to other web
based applications.  Somebody knowledgeable jump in here and help me.
I'm drowning.

Tom VandeWater

The XML definition I found on answers.com follows.

(EXtensible Markup Language) An open standard for describing data from
the W3C. It is used for defining data elements on a Web page and
business-to-business documents. XML uses a similar tag structure as
HTML; however, whereas HTML defines how elements are displayed, XML
defines what those elements contain. While HTML uses predefined tags,
XML allows tags to be defined by the developer of the page. Thus,
virtually any data items, such as "product," "sales rep" and "amount
due," can be identified, allowing Web pages to function like database
records. By providing a common method for identifying data, XML supports
business-to-business transactions and has become "the" format for
electronic data interchange and Web services.

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Johnson, Alex P (IPS)
Sent: Monday, March 26, 2007 3:44 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] client server

Re: ArchestrA (R) was handling everything in XML.  =3D3D3D3D


It doesn't handle everything in XML.


Regards,
 =3D3D3D3D

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 David Johnson
Sent: Monday, March 26, 2007 1:23 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] client server

Jeremy, if you and Tom weren't usually so right I wouldn't bother =3D
=3D3D3D3D

with this, but....

I though Archestra (R) was handling everything in XML.  Why not use
=3D3D3D3D

that with a published I/A schema, then we could roll our own =3D3D3D3D

Archestra tools to take advantage of all of that stuff.  I can see a
=3D3D3D3D

lot benefit with XML.


Regards,
David


 =3D3D3D3D

 =3D3D3D3D

_______________________________________________________________________
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
 =3D3D3D3D

foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3D3D3Djoin
to unsubscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3D3D3Dleave
 =3D3D3D3D




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


=3D3D3D20
=3D3D3D20
_______________________________________________________________________
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
=3D3D3D20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =3D3D3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3D3Djoin
to unsubscribe:      =3D3D3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3D3Dleave
=3D3D3D20
 =3D3D

 =3D3D

_______________________________________________________________________
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
 =3D3D

foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3Djoin
to unsubscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3Dleave
 =3D3D




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


=3D20
=3D20
_______________________________________________________________________
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
=3D20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Djoin
to unsubscribe:      =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Dleave
=3D20
 =

 =

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