[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Standards for EOD Data Providers



PureBytes Links

Trading Reference Links

John:

You hit the nail right on the head.  I was going to send you this message privately, but I felt your message was so accurate that it deserved re-posting on the metastock list.  Wake up EQUIS.

Don Hughes
daringdon@xxxxxxxxxxx

*********** REPLY SEPARATOR ***********

On 1/5/99, at 3:10 PM, John R. Fritch wrote: 

>From: "John R. Fritch" <jfritch@xxxxxxxxxxxxx>
>
>Alain:
>
>    I find it incredible that anyone who has used both Equis and QP
>would have anything good to say about Equis. With regard to API's,
>I've found QP's DLL's to be complete and very easy to implement. In
>less time than it takes Equis to upload my request to give me the
>day's activity on the three U.S. exchanges (ca. 14 minutes), QP2
>downloads that information, updates my database with it, and then
>allows me with its read DLL's in Visual Basic to translate the entire
>QP2 database into Swahili or any other format you can dream up.  So
>what need is there for "write API?"  With regard to support, the best
>support is that which is never needed, and QP's support of its DLL's,
>despite all the recent program changes, comes close to this standard.
>I've had one problem, and it was fixed with appropriate priority.
>
>    There are significant issues regarding QP's products and service.
>But when it comes to comparing QP with its “competition,” I just don’t
>see that QP has any competition.  I wish that it did have competition.
>I don’t like not having a real choice.  But presently, there is no
>real choice.
>
>    Quotes Plus is the only vendor which seems to understand that
>there is absolutely no reason why maintenance of their customers'
>databases should ever require them to see or specify a single security
>name or ticker symbol.  There is no legitimate excuse for acquisition
>and maintenance of stock data causing as much trouble and squandering
>as much time as it does.  So many other much bigger and more
>complicated things get done without much hoopla or a second thought.
>In comparison to the requirements of other technical disciplines, our
>needs seem reasonably modest.  For a historical data base of ticker
>symbol, date, open, high, low, close, and volume for all securities
>traded on NYSE, AMEX, and NASDAQ, we need:
>
>1) Early and snappy daily updates of our databases with the current
>day's trading data. With a typically two-minute download followed by a
>typically two-minute database update procedure completed by 6:30-7:00
>pm New York time, Quotes Plus satisfies this need.  With
>Equis/Reuters, you have a minimum of two problematic 40-minute
>download procedures that are often aborted in repeated failures until
>after midnight.  That’s in addition to the two ca. 14-minute uploads
>to Equis that accomplish nothing more than delivery of your request to
>download the day’s data.  With i-Soft's StockWiz, updates from
>downloaded files are plagued with inexplicable crashes.
>
>2) Automatic changes of ticker symbols and seamless accumulation of
>data delivered under the new ticker symbol onto that previously
>accumulated under the old symbol starting on the date the symbol
>change becomes effective.  Quotes Plus attempts to do this, but
>sometimes there is a delay of 1-3 days. It's done well enough that I
>don't have to worry about it or hassle with it.  With Equis/Reuters
>and i-Soft, you have to change the ticker symbols manually, and, if
>such change with Equis/Reuters is done after data has already been
>received under the new ticker symbol, you have to merge the data files
>for the new and old symbols.  In Equis/Reuters, notification of symbol
>changes is encrypted under the "additional information" portion of the
>download report. The notifications are often misleading, ambiguous, or
>just flat wrong, requiring you to go to external sources such as
>Zack's to get the real scoop.  i-Soft doesn't bother to give any clue
>regarding symbol changes.
>
>3) Automatic recording of stock splits and adjustment of price and
>volume historical data accordingly. Quotes Plus and Equis/Reuters do
>this.  Yes, information on all splits is easily accessible from the
>QP2 database.  For all practical purposes, i-Soft does not provide
>split information, and when you attempt to input a split factor
>manually, the program often mutilates your data.
>
>4) Automatic recording of distributions (e.g., dividends) and
>adjustment of historical price data accordingly.  Quotes Plus and
>Equis/Reuters do this.  i-Soft?  Forget it.
>
>5) Automatic recording of company name changes.  Quotes Plus does
>this.  For Equis/Reuters and i-Soft, the procedure is similar to
>ticker symbol changes.
>
>6) Automatic identification and correction of errors in data. Quotes
>Plus and Equis/Reuters do this. (Better yet, do it right the first
>time. What's the big hangup here?) Although they have far more data
>errors than their competitors, i-Soft would never even admit to
>sending bad data, let alone correct it.
>
>7) Automatic addition of new securities to the database as soon as
>they start trading.  Quotes Plus does this.  With Equis/Reuters, you
>have to download, unzip, and search a new file of all securities once
>a month to find the new ones, which you must then add to your database
>manually.  This is a monumentally tedious task.
>
>8) Automatic deletion from the database of securities which are no
>longer traded.  With Equis/Reuters and i-Soft, this must be done
>manually.  With Quotes Plus, this is not done as promptly as it should
>be, and occasionally becomes a problem.
>
>9) Direct, practical, and free access to the entire database from any
>program of our choice.  Quotes Plus accomplishes this by providing DLL
>procedures that can be used in anyone's Visual Basic or C++ program or
>any other company's application to retrieve directly and rapidly any
>information in the database.  With the 255 or even 2000 security per
>directory folder limitation, Equis/Reuters makes a deliberate and
>calculated effort to prevent you from even building let alone
>accessing a complete database.
>
>    At the risk of exposing my ignorance, it would seem that there
>might be an even better way to provide direct, practical, and free
>access to the entire database from any program of our choice.  Why not
>just build and maintain a single core database as a single large
>delimited ASCII text file containing the entire database as records
>with ticker symbol, date, open, high, low, close, and volume fields
>for all securities and all days?  Aren’t speeds and capacities of
>reasonably priced hard disks, RAM, and microprocessors finally great
>enough to handle expediently such an ASCII text file, even for ten
>years of 30,000 securities?  Anybody or anybody's program could open
>such a file and get the data they want when they want it. There would
>be no data conversions nor smoke, mirrors, or excuses.
>
>    I have to seriously question the motivation of any data or TA
>software vendor who asks me to store a database in some other data
>format, particularly one involving a proprietary encryption without
>supporting read DLL’s. The cost of providing any additional hard disk
>storage space required by an ASCII format is negligible.  Compute time
>penalties with an ASCII format might be more significant, but are they
>still sufficient to justify putting up with all the insidious software
>glitches encountered with trying to use encrypted databases?  I doubt
>it.  Furthermore,  any compute time disadvantage with an ASCII format
>will only continue to diminish.
>
>    Now if a data or TA software vendor asks me to store my database
>with their proprietary encryption without supporting read DLL’s, why
>am I to believe that their intent is anything other than to put and
>hold me in the bondage of their data feed and/or TA software?  (I am
>amazed at how many people just won't let go of their "precious" old
>MetaStock data!)  Why won't they provide data in a form that I can
>access efficiently from my own programs or other companies'
>applications, or, better still, that I can read directly from a text
>file?  There simply is no excuse for not doing so.  It’s time to “just
>say no” to vendors who won’t.
>
>                                                    John Fritch
>
>
>
>
>------------------------------------------------------------------------
>To unsubscribe from this mailing list, or to change your subscription
>to digest, go to the ONElist web site, at http://www.onelist.com and
>select the User Center link from the menu bar on the left.