Re: Which database support?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Actually, I finally found an article. However, it doesn't seem to give anything useful.
For example, it presumes that the user is apparently interacting with the database through
something like an MSGrid control. The problem is that I know part of the application
domain involved (I'm involved in a different part of it) and at no time will any data ever
be visible on the screen. Data will come in from a variety of sources (think of them as
streams; I'm generating one of them. Think of the language as a legacy language with some
XML-like properties). For example,

<data:record type="A" <data:pairs <data:xy x="123" y="456"/> <data:xy x="789" y="1011"/>
.... /> />

(Yes, I know that isn't pure XML syntax, but I didn't invent the language; it is legacy
and I'm fudging a lot to avoid some NDA issues). This data will be entered into a
database, and pretty much all that will appear on the interface is a progress bar. After
the data is read in, another app is going to read the data and analyze it, and build up
some new relations. Finally, the data will be plotted in a multidimensional graph. At no
time, ever, will there be a direct display of a record or recordset as a set of value
controls on a screen. No edit boxes, no MSGrid. Just data streams to the DB, analysis
based on selection, sorting, and a few similar operations, then plotting using a private
library. So all of the discussions I've found about 'data-bound controls' is pretty
useless. Also, connection will be to a variety of databases, so there will be no single
name to be used (apparently the name somehow gets bound at design time, and information
about the fields. For their needs, this is all-but-useless. The names of the fields are
determined by one application and the other application will have a database associated
which has multiway relationships, intersection tables, etc. all of which will be filled in
based on the incoming data stream).
joe

On Fri, 8 Jul 2005 17:45:29 -0400, "Roy Fine" <rlfine@xxxxxxxxxxxxx> wrote:

>Joe,
>
>ADO is likely the better way to go, although ODBC is a close second. DAO
>is OK, but *only* if the target database is based on the MSFT Jet Engine
>(e.g. MS Access database, although MS Access is not a requirement, just the
>Jet runtime)
>
>ADO is built on OLEDB; Both are based on a set of interfaces defined by
>Microsoft, so don't expect to see any provider specific capabilities
>available in either. ADO, when compared to OLEDB, provides a lot of
>features that can cut the development time by a factor of 10 or better.
>Performance is comparable, especially when accessing a database over a LAN.
>The ADO typelib, with the #import directive, provides a good set of
>smartpointer classes and exception handling wrapper functions - and that has
>a very positive impact on application robustness as well development time.
>The documentation for ADO is quite good - albeit mostly written for the VB
>programmer. Documentation for OLEDB is pathetically inadequate.
>
>ODBC is ODBC - it has been around for a long time. MFC has good support for
>connections and recordsets, but little else; ODBC has a lot of capabilities
>and is a decent performer when programmed at the API, but is a bit tedious
>(falling somewhere between ADO and OLEDB in this regard). Documentation for
>the ODBC is good compared to OLEDB, and is comparable to that of ADO.
>
>OLEDB and ODBC drivers exists for the popular databases - SqlServer, Jet,
>Oracle, MySql, etc, etc... ADO will work for any database technology that
>provides an OLEDB implementation.
>
>regards
>roy fine
>
>
>
>
>"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
>news:dnptc1puootpg9ibkrqe3epqg148ecrvgf@xxxxxxxxxx
>> I don't do databases much (well, the last database work I did was about
>eight years ago).
>> But one of my clients needs to understand which of the many buzz-acronyms
>should be used
>> for database work. DAO has apparently been deprecated in VS7, which leaves
>ADO, ODBC and
>> OLEDB as options. To me these are largely meaningless terms, but if anyone
>has a
>> suggestion I can pass on as to which way new development should go, I'd
>appreciate it.
>> joe
>>
>> Joseph M. Newcomer [MVP]
>> email: newcomer@xxxxxxxxxxxx
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Cannot display ODBC login prompt - want to connect without DSN
    ... ODBC was superseded thirteen years ago by OleDb: ... In this particular case, my program will conect to an Oracle database, but ... There does not seem to be a .NET provider for MS Access, ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Which database support?
    ... ADO is likely the better way to go, although ODBC is a close second. ... but *only* if the target database is based on the MSFT Jet Engine ... ADO is built on OLEDB; Both are based on a set of interfaces defined by ...
    (microsoft.public.vc.mfc)
  • Re: ADO connection with VBS to locally stored MS-Access database
    ... Even using of the OLEDB Jet provider is better, I do not see any confusion ... You could use ODBC or OLEDB syntax but in this case ADO will using ... > I am trying to connect to a local Access database via ADO and VB Script. ...
    (microsoft.public.data.ado)
  • Re: Is ADO Dead (3)?
    ... The Design of ADO ... ADO uses a single object, the Recordset, as a common representation for ... a forward-only stream of results from a database, ... where data is updated at the data source or cached locally as with the ...
    (comp.databases.ms-access)
  • Re: Is ADO Dead (3)?
    ... The Design of ADO ... ADO uses a single object, the Recordset, as a common representation for ... a forward-only stream of results from a database, ... where data is updated at the data source or cached locally as with the ...
    (comp.databases.ms-access)