Re: I can attach in SQL Server, but can I in Oracle?

Hans,

I have a "niche market" engineering app that is generally used by a small group of users in the generating side of the electric power industry. Specifically, my app is used by a small number of people at a generating company with an overall company "administrator". The individual "users" at each client's site are working on different plant data so any single user is not walking on the other users' data. Only the single administrator is likely to raise a concurrency issue with one of the users. In my 15 years of experience with this application, this is not a significant issue -- yes, it is a part of the design consideration and the VS code does include concurrency checking -- in addition to considering Oracle's multiversion concurrency control. (The use of SCNs is pretty cool actually)

The reason that the multi-datasource issue has arisen is that clients want to have these databases administered by their inhouse I/T folks (backups, security, etc). Well, as you can imagine, I have clients that are either Oracle shops or MS shops -- thus the reason for now needing both Oracle and SQL Server installations.

Back in the 1980s the app was developed with Clipper and used dBase files. It was later migrated to VB/C/C++ and used Access. The current migration is to VS.NET and Access/Oracle/SQL Server.

If I were doing the reservation system for American Airlines, a lot more of the issues you describe below would be paramount. That's not to minimize the recommendations you make below in any way, but in the design basis I have for this application, it's not the same level of importance that it would be in the AA reservation system.

[Quoted] One of my larger clients has 280 generating units and they have only generated about 300,000 data records in 21 years of collecting this data -- that's total; so it averages about 50 records per unit per year (some units will collect as many as 500-600 records in a calendar year). So while scalability is a concern, it is a smaller concern than the AA example.

The application is primarily a data cruncher that uses a "snapshot" of the data taken after the data is "finalized" for the previous month. With the snapshot, the data is copied to a mirror set of tables so that the current data can be entered by the users while the administrator generates the required reports using the separate snapshot -- i.e., no concurrency issues at this point since they're using different sets of tables -- this is at the clients' requests. Anyway, wanted to give you a sense of the app design to understand a little about the basis for my responses to recommendations.

Thanks for your insight and wisdom. It is very much appreciated...

Ron

"Hans Forbrich" <forbrich_at_telusplanet.net> wrote in message news:3F352D7C.54EF3A03_at_telusplanet.net...
> Ron Fluegge wrote:
>
> > Daniel,
> >
> >
> > This is not counting the Oracle help and doc files installed with both
8i
> > and 9i that I have searched and attempted to understand as well. I have
> > read every MS/MDSN/Visual Studio/.NET Mag article regarding connecting
with
> > Oracle from the 1.0 and 1.1 versions of the Framework that I could
find --
> > some of which were written by Oracle staff. Could I have read more?
Yes.
> >
>
> Jumping into the middle .....
>
> The point of "SQL Server vs Oracle design" has been raised a few times -
let me
> restate it this way: "In spite of many
attempts/frameworks/methods/patterns to
> provide universal RDBMS independance, the fundemental design differences
of the
> RDBMSs can cause unexpected situations to occur under varying load,
data-size
> and/or dataset conditions. Many software developers have developed
towards a
> single RDBMS or framework which appears to have been acceptable in a test
> harness, and have found that a significant change in environment has
caused
> exceptional results."
>
> The above is just suggesting you keep your eyes wide open: I've had many
> discussions with developers after they've designed toward a specific
pattern and
> then having difficulty scaling that pattern. The most common issue tends
to be
> designers developing towards SQL Server for a certain load size, switching
to
> Oracle to handle much larger loads, then not understanding why the system
> doesn't respond [in a linear scale].
>
> Hope this is not true in your case.
>
Received on Sat Aug 09 2003 - 20:15:48 CEST