Re: Informix vs. Sybase vs. Oracle vs. (gasp) MS SQL Server

The complete posting I am responding to follows my comments.

For us "rookies" could some one post some specific examples as to what you are proposing as solutions. I have a general idea of the problems you are discussing, but everyone says, "With proper planning you can identify the solution."

What does this mean in specifics? Do you do 1 row per page? Do you design your files differently? Or is your code written to work around this solution?

I appreciate everyone taking the time to discuss this issue, but by now all comments have bolied down to either "row locking is better" or "no it's not".

Can anyone be more specific about this? What steps can be taken to resolve this?

Does this issues matter to smaller systems? In rough terms when does this become a problem? How many files and how many records must exist before you run into the locking vs performance issue?

Let me give one example of how I handled a problem in Foxpro. Whenever I ran into an invoice type of situation, ie invoice with many items on it, I kept a summary type of field to hold totals. But I also wrote a routine that recalculated the total every time a user called up that invoice. It worked well in Foxpro. I mentioned this to some rookies who only calculated the total at time of input. They were having trouble because every time someone change an item, it cause the total at the invoice level to be out of sync with the actual total of the records in the items database.

Now I don't know if this type of coding would work in the SQL arena. I mention it to show that I discover a way to handle a Foxpro problem, and I showed the general approach to show new programmer to help them.

Can anyone give some specific advice as to this problem?

Thanks,
Al Frick

On Fri, 05 Dec 1997 18:57:01 +1000, Anthony Mandic <no_sp.am_at_agd.nsw.gov.au> wrote:

>Gary Kuever wrote:
>>
>> >Sorry, but I've seen page locking problems in OLTPs, usually because of
>> >multi-part transactions on POS (Point of Sale) systems.
>>
>> Sounds like a case of incomplete design, but I wasn't there. My point is
>> that there is nothing in PLL or RLL that guarantees a database problem with
>> incomplete requirements, poor forethought, bad design, qucikie development,
>> etc.
>
> Now here's an example of someone who knows how to think,
> and not only that, has the experience to recognise the issues.
> Gary, I tip my hat to you.
>
>> >Yes, there are workarounds. One system supports more than 700
>> >concurrent users, but it takes a lot of forethought to make
>> >sure that different inventory items don't share a page. During the
>> >Christmas rush, it is naive to think that there won't be contention
>> >between users for a single page of data.
>>
>> I've never designed or been a participant in a system that had any
>> significant contention. If that makes me naive in you book, so be it.
>
> I've worked on a system recently where there used to be contention,
> but I was able to resolve the problem with rather trivial
> changes. Its just as you said Gary - poor forethought, bad
> design, etc. Luckily, I was able to recognise this and identify
> the correct solution and enact it. It isn't exactly hard.
> So why do some of the participants in this debate seem to
> think so?
>
>-am
Received on Sat Dec 06 1997 - 00:00:00 CET