Re: [foxboro] client server
- From: "Johnson, Alex P \(IPS\)" <alex.johnson@xxxxxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Thu, 29 Mar 2007 17:21:24 -0400
Chuck,
Re: SQL Table
When I wrote "SQL table", I should have written "tables in a Microsoft
SQL Server database."
There is no chance that we will publish the data in a different database
- no Oracle, no mySQL, no PostgreSQL, no way, no how.
I regret any confusion that my lack of precision may have caused.
Re: All
The question I asked was intended to elicit arguments for and against
different formats. =
I had three goals:
1) Since each format that we support costs money and long term support,
we'd like to be sure that we pick the right one(s). Forcing a choice and
asking for justification seemed to be a reasonable way to do it.
2) Not all of the formats that I mentioned were understood to be
valuable to end-users and for that reason I wanted to see what was
considered valuable. If we don't think it is valuable, we won't support
it - whatever it is.
3) I was hoping to learn how the data might be used.
We might do all.
Does this help?
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 Jones, Charles R. (Chuck)
Sent: Thursday, March 29, 2007 1:46 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] client server
I am confused about part of our discussion and I would like to restate
an earlier question. I may be missing something.
Several responses refer to the capabilities of MS SQL *Server*. When I
re-read the original question, I find that Alex asked if we wanted the
information in the form of SQL *tables*. The question then was, "Given
that it [the data] is a report, what can I do with an SQL table that I
cannot do with an Excel spreadsheet?" Restating the question, "What
information can we get from the data if it is in SQL form or XML form
than we cannot get if it is in ASCII?" It is the exact same data! The
only thing I see that we get is ease of use. The important questions
for me then are:
o What format am I going to use it in most of the time?
o How many steps do I have to be manually involved with to get it there?
o What other, more useful, forms could I be storing the data in (the
point of this message)?
I agree with Jeremy that SQL rocks--even MS SQL. :) Getting the data
there could be very useful. I also agree with Corey that the data needs
to be available to Unix platforms as well as MS platforms. I agree with
Kevin that XML has great potential, but I don't know enough about it to
give it a recommendation. I can live with any of the solutions.=3D20
Though I run a Unix platform, I do most of my system planning on my MS
laptop. As a result, my preference order and my concerns are:
1) SQL Tables
If the data is presented in SQL format, it should be saved in a
widely-used format. Are .dbf files still common to all databases? Can
MySQL and PostgreSQL open MS database table formats? =3D20
2) Excel workbook
OpenOffice Calc can open Excel spreadsheets, but can it import an SQL
table like MS Excel can?
3) Delimited ASCII files with headings
Delimited ASCII is friendly to both Unix and MS and it is the lowest
common denominator, as Corey stated. But, as such, it requires the most
refining to get knowledge out of the data. =3D20
4) XML files
If it comes in XML format, it needs to be user friendly--very friendly.
And, I am sure it will be, so I am okay with it.
Given that changing from SQL table to spreadsheet to ASCII is trivial,
it makes me want to ask for the negated fifth choice. How hard would it
really be to have "All" as an option? It will probably only have to be
figured out once. If iccprt has not changed much over the years, then
this solution would probably not have to fork later on down the road
either. It would be similar to selecting the save format of a document.
I am just asking... :)
************************************************************************
***=3D
**************************
This email and any files transmitted with it are confidential and
intended =3D
solely for the=3D20
use of the individual or entity to whom they are addressed. If you are
not =3D
the intended=3D20
recipient or the person responsible for delivering the email to the
intende=3D
d recipient, be=3D20
advised that you have received this email in error that any use,
disseminat=3D
ion,=3D20
forwarding, printing, or copying of this email is strictly prohibited.
If =3D
you have received=3D20
this email in error please notify the sender immediately. Please note
that =3D
we reserve=3D20
the right to monitor and read any emails sent and received by the
Company i=3D
n=3D20
accordance with and to the extent permitted by applicable legal rules.
************************************************************************
***=3D
**************************
=
=
_______________________________________________________________________
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
- References:
- Re: [foxboro] client server
- From: Johnson, Alex P \(IPS\)
- Re: [foxboro] client server
- From: Jones, Charles R. \(Chuck\)
Other related posts:
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- » Re: [foxboro] client server
- Re: [foxboro] client server
- From: Johnson, Alex P \(IPS\)
- Re: [foxboro] client server
- From: Jones, Charles R. \(Chuck\)