Re: RDB limitations
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 13 Oct 2008 00:40:47 +1300
"billious" <billious_1954@xxxxxxxxxxx> wrote in message
news:48f188ef$0$10607$5a62ac22@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
"Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:6lctacFbnqs3U1@xxxxxxxxxxxxxxxxxxxxx
There are a number of things you can do with ISAM which a Relational DB
doesn't like and won't let you easily do.
For example,
let's say you are using START... READ NEXT to sequentially or
skip-sequentially process a series of records.
You can issue a WRITE, REWRITE, or DELETE against any record you fetched
or against other records that have nothing to do with what you fetched,
and READ NEXT faithfully remembers where it is up to. (Not only that, but
your updates are applied immediately with no waiting on deferred COMMITs.
Of course you can't roll them back either...)
This functionality can be matched (albeit, primitively...) by opening a
cursor in ESQL.
Fine and dandy.
Trouble is, if you want to replace any of the records you fetch, or race
off and update some (un)related records, you can lose your cursor very
quickly. There are options in SQL to deal with this but they apply to
specific instances and it is hard to generalise them
I was testing a Data Access Object yesterday and everything was going
fine until we got to the bit where I started throwing updates, inserts
and deletes into the same object that was running my cursor. Worked
sometimes. (I realized later it actually depended on where the cursor was
positioned and whether what I was accessing was in the cursor range or
outside it... all very interesting...). Unfortunately, "sometimes" is not
an option for software that people are paying for, so I had to find a
solution to this problem.
These objects have generalised methods to deal with sequential,
skip-sequential, and random access, as well as any maintenance. But it
really got its knickers in a twist when I required it to run a cursor
while dealing with everything else. After spending a couple of hours
looking for non-existent bugs, I hit the books and found that these
limitations are documented.
Most of the solutions which occurred to me were messy and ugly...
recognise when an update action was about to occur, save the current
cursor position and re-open it automatically on the next FETCH...always
declare cursors as updateable and non-static (but that doesn't help with
related records that must also be upated)... that kind of nonsense.
Before I tell you how it was solved, with a general solution that works
for any kind of access and access pattern that ISAM can do, with
immediate commits that faithfully emulate the ISAM processing, has anyone
here experienced this kind of problem when mixing SQL maintenance with a
running cursor?
Sure, for a specific case you can use positioned updates and play with
cursor isolation, but isn't it a pain?
I really am coming to the conclusion that cursors are "best avoided"...
they're so primitive and really only necessary with COBOL (I don't use
cursors with Java, C#, or VB) because it doesn't easily handle result
sets, and is grounded in ISAM skip-sequential processing.
Thoughts/opinions/comments/experiences, please.
Pete.
--
"I used to write COBOL...now I can do anything."
SUPRA gives you a unique 4-byte record ID for each record you retrieve, so
navigating is a doddle. You can even switch the index you're using
part-way through if you want, then jump back to any record and continue
along another index - records are stored as a (number) of one- or two-way
linked list(s.)
It's a product I have never heard of, and sounds interesting.
All the advantages of ISAM and RDB in one product...pity about the price
and support though... :(
Ah, yes, support... not a lot of it about is there?
Ever thought about how rare it is to see someone say they got fantastic
support for a software product they may well have paid thousands of dollars
for?
A while back I decided to support myself.
(With the right tools, it isn't as hard as you might think. If you have a
mainframe background from the old days and are used to poring over dumps and
following event chains and control blocks, you are halfway there already.
Visual studio can attach to a running process and let you trace and monitor
it, as well as helping you analyse stack dumps and traces. After you do a
few, it isn't so hard. I managed to fix some problems with Fujitsu COBOL a
few weeks back, by doing this. I was able to determine exactly what it was
doing and why it crashed.(the compiler .dlls, not the application). I could
then adjust the application to get round it. Now, I'm not suggesting
everybody should cancel their maintenance contracts overnight, but, if you
aren't getting any value for it and are treated like an idiot every time you
request maintenance, then it could make sense. One of the things which
persuaded me, was paying significant amounts for support which simply gave
the wrong (or no...) solution. Go through the paper work, fill in the forms
(online, if you're lucky) then wait days for a wrong answer... And pay for
the "privilege"? I think not...)
The clincher for me was being on a customer site and having undocumented
messages in pidgin English appearing from PowerCOBOL. Then being told by
Fujitsu support to wait three weeks while they sent the stuff off to Japan
to find out why it was doing it. In four days (and nights...) I rewrote all
the PowerCOBOL COM classes as NetCOBOL COM and got the system implemented.
I've never forgiven them for the anguish and stress it caused, and it was a
major factor in moving me away from COBOL.
One advantage of "going with the flow" (whether it be MicroSoft or LAMP) is
that there are millions of people out there who already found the same
problem you have encountered. These days I go straight to GOOGLE and have
what I need in minutes, for free. (To be fair, I try to contribute as well,
and have managed to help a few people in various forums...)
SUPRA sounds like a good product. Wouldn't you think they'd be precious
about it and take care of the customer base that uses it?
For myself, I personally guarantee the software I write. For life. (mine or
the software's... whichever ends first.). If you have something from me that
doesn't work the way it is supposed to, I'll fix it, or refund your money.
No arguments, no weasel clauses, no equivocation. (So far, no-one has ever
had a refund :-) But I have burned some midnight oil producing fixes on a
few occasions... :-)).
I have never understood why a company would invest millions in developing
software, but consider that supporting it was just an overhead, rather than
a core business requirement.
Pete.
--
"I used to write COBOL...now I can do anything."
.
- References:
- RDB limitations
- From: Pete Dashwood
- RDB limitations
- Prev by Date: Re: RDB limitations
- Next by Date: Re: RDB limitations
- Previous by thread: Re: RDB limitations
- Next by thread: The solution WAS: Re: RDB limitations
- Index(es):
Relevant Pages
|
