× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: AS/400 Gasping For Air ??
  • From: Don Schenck <schencd%AM_LZCH%VASELL@xxxxxxxxxxxxxx>
  • Date: Wed, 06 Jan 1999 05:24:24 -0400
  • Autoforwarded: false
  • Disclose-recipients: prohibited
  • Hop-count: 2
  • Importance: normal
  • In-reply-to: <4.1.19990105223009.00931870@pop.inwave.com>
  • MR-Received: by mta TIMONE.MUAS; Relayed; Wed, 06 Jan 1999 05:24:24 -0400
  • MR-Received: by mta VASELL; Relayed; Wed, 06 Jan 1999 10:23:54 -0400
  • MR-Received: by mta MPMV04; Relayed; Wed, 06 Jan 1999 10:23:47 -0400
  • Sensitivity: Company-Confidential
  • UA-content-id: 11D132981700
  • X400-MTS-identifier: [;0924241006011999/A15584/TIMONE]

::::At 00:34 01/05/1999 -0500, Booth Martin wrote:
::::>Pete, what does "not scale very well" mean?  Are we to think of one or two

::::>users, or 8, or 15, or 3,000?
::::
::::I've got 30 or so users running against a read-only Access database with no
::::problems, however, if several (meaning 2 or more) open it for update, they
::::have problems with lock conflicts because it seems to use a disk sector
::::locking algorithm. There is also little in the way of security. It's an all
::::or nothing proposition. Nothing at even at the table level. It doesn't do
::::triggers either, although it does handle constraints fairly well. I can't
::::comment on what happens if you have a large table. You do need to compress
::::the database regularly. I've had trouble with databases becoming corrupt
::::while doing automated compress operations. SQL Anywhere is a lot better for
::::not much more money.
::::Pete Hall


Pete --

The JET database locks 2,048 BYTES. The "trick" is to pad all your tables with
a text field or fields so that the record length equals 2,048 bytes or a
multiple of that.

Security is addressed -- in Visual Basic, anyway -- by implementing a "Data
Server" object that marshalls all requests and validates the user.

Compresses (Hmmmm ... sounds like a System/36!) can/should be scheduled to run
evenings or weekends.

You are correct, however, when you recommend a different RDBMS engine. "The
right tool for the job" is a good idea -- one every zealous RPG programmer
doesn't share, I might add.

<grin>

I'm working on a huge three-tier project right now for a pharmaceutical giant.
I tested my Business Rules object this morning, and loaded 4,000 records from a
JET database (called "qis.mdb") on our development NT server into a list box.
>From qis.mdb to a collection to a listbox on a form took four seconds. Not bad.

I expect the SQL Server 7 performance to shave a second.

Would I rather be hitting a DB2/400 database on a RISC box? YOU  BETCHA!

Peace,

-- Don Schenck
www.SchenckTech.com

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.