HDTenEightyP/NetNews huggingface dataset:
From: Mischa_Sandberg@mindlink.bc.ca (Mischa Sandberg)
Subject: Re: 500'000 records - who does best?
Organization: MIND LINK! - British Columbia, Canada
Date: Tue, 29 Dec 1992 19:47:16 GMT

> Mark Baldridge writes:
> >It isn't the number of users, it's the basic size of the tables.
> >One of our clients has pushed a table to 900k rows, 250Mb on an RS/6000
> >with 50Mb memory dedicated to the Sybase server. Working with it
> >feels like retiling the bathroom while an elephant uses the john.
>
> Maybe I am missing something, but we routinely have customers with 250 to
> 800
> megabyte tables and 200-300 users on RS6000s.  Earlier this year, we did a
> benchmark with 1600 users, all with under one or two (I do not remember
> now)
> second response time.  The benchmark was to ensure that the fully
> configured
> system could handle the expected 2500 users.
>
> We use uniVerse.

Pardon my ignorance as to what uniVerse is.

I suspect we are talking about different kinds of apps here, in which
case you may find Sybase or Oracle or what-have-you to be plenty good
(but perhaps you could expand on what uniVerse is or does). Sorry,
from your original posting I thought you were having a problem.

"one or two ... second response time" suggests that your client users
are perform transactions on a limited number of rows, and from the numbers
I suspect that your chief concern is TPS. B-tree or (even better) hashed
access time doesn't rise dramatically with table size, and you probably
aren't even really interested in clustering and contiguous allocation.
Furthermore, I'd wager that database changes once the system is in production
are not a major concern, either.

In any case, I'm impressed by anything
running on a Unix box, presumably with TCP/IP connections, actually
handling 1600 or more concurrent requests, which amounts to 1K TPS
or better --- assuming that is what you indeed mean by "1600 users".
Our systems "handle" a few hundred users, but with only a couple dozen
connected at one time :-).

The kind of transactions that concern me are high-activity requests,
i.e., where nearly every transaction involves a significant chunk
of the table. Our servers receive remote updates over a WAN that
are EACH typically 1-10k rows; and alterations to the running system
occur on a monthly basis, typically requiring all rows to be updated
(this is the way the apparel business works).

So, we may well be talking about completely different problem domains.
I'd be interested in hearing more about the specifics of yours.
Did I miss it when you mentioned exactly what these 30K records contain?


--
Mischa Sandberg ... Mischa_Sandberg@mindlink.bc.ca
                 or uunet!van-bc!rsoft!mindlink!Mischa_Sandberg
*-*-*-*-*-*-*-*-*-*-*
Engineers think equations are an approximation of reality.
Physicists think reality is an approximation of the equations.
Mathematicians never make the connection.
Newsgroups: comp.databases
From: John_Carson@mindlink.bc.ca (John Carson)
Subject: Re: Info hiding v/s data abstraction
Organization: MIND LINK! - British Columbia, Canada
Date: Sat, 26 Dec 1992 23:41:49 GMT

> Yashesh Bhatia writes:
>
> Msg-ID: <1992Dec26.223412.29634@cs.brown.edu>
> Posted: Sat, 26 Dec 1992 22:34:1
>
> Org.  : Brown Computer Science Dept.
>
> Could someone let me know if there are dufferences between these two terms
> and if so what are the pro's and cons of using one for the other in the
> world of databeses and s/w eng.
>
> thanks


Data abstraction and hiding data.

1) Data abstraction is removing the database #1 and placing into database #2
and based on a certain condition. Then manipulating it to your needs.

2) Hiding data is like setting a filter so you only see what you want based
on the filter condition.

I personally have used both and I feel the DATA ABSTRACTION is the best if
your original database is very large to start with. Otherwise I use the
filter system.

John
--
>>>>>>>>>>>>>>>>>>> John_Carson@MINDLINK.BC.CA <<<<<<<<<<<<<<<<<<<<<
>>        D.John Carson    J & H Concepts   (604)589-5118         <<
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Newsgroups: comp.databases
From: johnh@borland.com (John Haskey)
Subject: Re: DBASE III/IV MDX,NDX, DBT
Originator: johnh@genghis.borland.com
Organization: Borland International
Date: Wed, 30 Dec 1992 19:43:08 GMT

Alan, Steve,

	A document describing the format of all dBASE files including the .MDX
is available from Borland's developer services program.  I don't have a direct
contact number handy but I'm sure you could dial (408) 438-8400  and ask the
corporate receptionist to direct your call...
								---john.
-- 
johnh@genghis.borland.com ---------- This post contains 100% personal opinion!
"...there are at least 9 Redwood Drives in Santa Cruz county, plus 5 Roads, 
4 Avenues, 3 Places, 3 Streets, 2 Terraces, 2 Ways, and 1 each of a Lane and
a Circle, all, presumably named for the Redwood Tree." -S.C. County Place Names
From: ericj@teal.csn.org (Eric Jacobsen)
Newsgroups: comp.databases
Subject: Re: Advanced Revelation information request
Date: 21 Dec 92 15:56:16 GMT
Organization: Colorado SuperNet, Inc.


Thought I'd add some more confusion on AREV validation/integrity options:

>In article <1globmINNn4t@crcnis1.unl.edu>, price@helios.unl.edu (Chad  Price) writes:
>> clinton@acs.ucalgary.ca writes:

>>>	Does it support integrity rules in the dictionary?
>> Not directly, but you can create "symbolic" fields which are in effect programs
>> to ensure data integrity, and there are hooks into the data entry screens to
>> allow inclusion of these symbolic fields for data validation. In fact, if you
>> write the validation code before you create the screen, it is automatically
>> included. 

>Hmmmm.... actually, I would say ARev _does_ support integrity rules in the
>dictionary... ARev data dictionaries contain 'Edit' constraints which can be
>any of a wealth of 'canned' constraints [dates, numeric fields, pattern
>matching, etc..] and can also contain custom constraints through "symbolics"...
>once you define these edits, they are bound to the data element in any future
>reference to that element - but this is limited to Paint... so a little caution
>is prudent - you CAN bypass the edits...

There are actually several levels of integrity checking, which can
be combined:
   - field-level validation on screen input
   - screen-level validation on screen input
   - record read/write validation on *any* file operation

The first two can be any program you would like to write, and
frequently are very simple.  (Though for some things I do are
quite complex.)

The last one is done through layered filing systems.  You can
put your own subroutine in a stack of subroutines that gets called
to perform record reads/writes, and all other file accesses.
AREV calls this a "modified filing system".  In fact, this is
how indexing works -- AREV creates an MFS to perform index updates.
Through this methodology, you can insert whatever sort of validation,
encryption, or audit trails that you like.  It's perhaps not something
for everyone, but if you need it, you won't find it in any other 
products.

Also, the "canned constraints" referred to above can also be
customized, through user-defined-conversion routines.  Throughout
AREV, there is the concept of 'conversion', which separates
the stored internal data format from the users' view of the
data.  For instance, dates are stored as an integer, but displayed
as a date (i.e. 12/21/92 or Dec 12, 1992).  You can write your
own conversion routines, which can also perform validation.


Eric Jacobsen
ericj@csn.org
[Colorado Revelation User's Group]
Newsgroups: comp.databases
From: paulr@bts.com (Paul Raulerson)
Subject: Re: FoxPro problem with outer join
Organization: Bux Technical Services -- Doylestown, PA
Date: Mon, 21 Dec 1992 20:11:08 GMT

In article <1992Dec21.012636.28374@gopher.dosli.govt.nz> srlncnc@gopher.dosli.govt.nz (Chris Crook) writes:

I am a novice FoxPro programmer, though I can tear up SQL. <grin>
Indeed, if FoxPro supported a full SQL dialect, a SELECT with 
and UPDATE would work just ducky here. But since it doesn't, have your
tried just reading the entire second table into an array, then 
processing the first table using the array? 

Something like:

  select * from table2 into array myarray;

?
If that is a dumb idea, don't hesitate to tell me. :) 
-Paul


>
>Can anyone offer any advice on how to solve the following problem in FoxPro
>(other than by using Paradox!).
>
>I have a one table (table1) with the following fields
>
>    unique_key
>    field1
>    field2
>
>and a second table (table2) with the fields
>
>    unique_key
>    field2
>
>The key is common to the two tables, but table2 has only a subset of the
>key values that are present in table1.  I would like to do is replace the
>field2 values in table1 for which there is a corresponding key in table2,
>leaving the rest of table1 untouched.
>
>I cannot do an SQL join because I would lose most of table1 (ie the records
>for which a key does not exist in table2).  I would prefer to avoid using
>a SCAN on table2, because it could be SLOW!
>
>Have you any suggestions - is there anything obvious I have missed in the
>bulky manuals?
>
>Thanks in advance for any suggestions.
>
>
>Chris Crook


Newsgroups: comp.databases
From: john@jlc.mv.com (John Leslie)
Subject: Content-Based Retrieval
Organization: John Leslie Consulting, Milford NH
Date: Sat, 02 Jan 1993 16:38:30 GMT

mike@uunet!tellab5!odgate (Mike J. Kelly) writes:
>
> As far as I know, no one has yet integrated content-based retrieval (CBR)
> with BLOBs and large text fields, which is what you really want...
>
> It might be interesting to the vendors who are reading this group if we
> were to start a thread on what a CBR-BLOB capability would look like.

   I second the motion.  Of course, right at the start we have a problem.
CBR-BLOB is an oxymoron.  A Binary Large OBject does not *have* contents
interpretable by the database engine -- interpretation, by definition, is
up to the application code.

   Nonetheless, it is clear that people *are* going to store ASCII text
in BLOBs.  There are straightforward things we can do with arbitrary
ASCII text; and we could design the engine to degrade gracefully if it's
asked to do these to non-ASCII BLOBs.

> The way I conceive it, at its simplest, it would involve a new type of index
> ("create text index"?) which would set up a varchar or BLOB column to be
> retrieved via CBR operators, along with some new CBR operators (at least
> contains, and probably more sophisticated stuff than that.)

   Text-indexing a BLOB should create a (variable-length) index capable
of being searched more efficiently to yield a large subset of the answers
to possible inquiries under the CBR expression parser.  Whether the BLOB
itself needs to be accessed to determine the final retrieval list seems
to me an implementation detail.

   Open Question:  In a client-server environment, is it acceptable for
the server to pass the *entire* CBR index to a client in order to perform
the CBR operation?

   The generally accepted operators are "contains" / "does not contain"
and "starts with" / "ends with".  I would think we should add multiple-
operand cases for "and" / "or" / "precedes" and "follows".  For long
text, usually there is a "within" <N> "words" / "lines" (etc.) clause
for multiple-operand searches.

   Open Question:  What is a reasonable limit to number of operands and
nesting depth?

   In practice, other fields are created to save disambiguating information
which is not easily generated from the text.  At user-level, we will need
expressions which cover multiple fields of the same record.

   Food for Thought:  As text gets larger, formatting becomes more and
more important.  Can we remotely hope for a definition of "rich text"
which clearly-enough distinguishes formatting information so that the
database engine can ignore it in generating the CBR index?

John Leslie <john@jlc.mv.com>
Newsgroups: comp.databases
From: rohrernl@helix.nih.gov (Nathan Rohrer)
Subject: Paradox 3.5 Error (too many registrations)
Organization: National Eye Institute, National Institutes of Health
Date: Mon, 21 Dec 1992 18:46:09 GMT

We are getting a strange "Unexpected Condition" error in Paradox.  We had a 
lot of tables up and when pressing the coedit key received "Too Many 
registrations leaving Paradox".  It also displayed #348.  Does anyone know 
what this error is and what could be causing it?



/*********************************************************************/
/*                       --- Nathan Rohrer ---                       */
/*  NATIONAL EYE INSTITUTE, OFFICE OF SCIENCE POLICY AND LEGISLATION */
/*              MANAGEMENT INFORMATION SYSTEMS SECTION               */
/* BITNET: NLR@NIHNEI31                  BETHESDA, MD 20892-0031     */
/* INTERNET: rohrernl@helix.nih.gov      NIH 3Com: NLR:NEI31:NIH     */
/* CompuServe: 70670,3164                PHONE: 301 496-2194         */
/*********************************************************************/
Newsgroups: comp.databases
From: James.Spaith@launchpad.unc.edu (James Spaith)
Subject: Paradox Error Message - Any Ideas?
Keywords: paradox novell memory data entry
Organization: University of North Carolina Extended Bulletin Board Service
Distribution: usa
Date: Thu, 24 Dec 1992 17:34:30 GMT

I'm using CoEdit to enter grade values from transcripts into a table
linked to a master table of names with which the grades are associated,
running Paradox 3.0 over Novell Netware 2.11.  Every once in a while, my
users (up to four at this point, hoping to have more very soon) get a
message "Unexpected condition - resync error - Leaving Paradox".  This
usually happens to only one person at a time and usually when they are
adding a new master record.  I'm currently experimenting with LOCKRECORD
and UNLOCKRECORD but without immediate improvement.

Can anyone tell me   a.  what the resync error is and  b. offer any
advice?  

Thanks a heap and ho ho ho!

jas


--
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  laUNChpad.unc.edu or 152.2.22.80
Newsgroups: comp.databases
From: mccon@ssdd475a.erim.org (Joe McConnell)
Subject: Re: Paradox 4: Problem with PushButton and ShowDialog
In-reply-to: ummalik@ccu.umanitoba.ca's message of 13 Dec 92 17:39:42 GMT
Organization: Environmental Research Institute of Michigan, Ann Arbor, Michigan
Date: 21 Dec 92 17:34:32

What CANCEL does on a pushbutton is "cancel" the dialog box.  Make
this one an "OK" button that gets the value of "Cancel" -- then
you'll have what you're looking for.
--
Joe McConnell  | Opinions expressed are the   | Don't blame me!  I voted for
mccon@erim.org | author's, not the employer's.| Stephen Maturin!
Newsgroups: comp.databases
From: andrews@microsoft.com (Andrew Sigal)
Subject: Re: MICROSOFT ACCESS vs FOXPRO
Date: 23 Dec 92 00:34:22 GMT
Organization: Microsoft Corporation

In article <BzFqyC.6LC@usenet.ucs.indiana.edu> tcheng@bronze.ucs.indiana.edu (Tony C. Cheng) writes:
>In <1992Dec16.224755.878@netcom.com> messina@netcom.com (Tony Porczyk) writes:
>
>>thomasd@tps.COM (Thomas W. Day) writes:
>
>>>No they're not.  You can get a position paper from Microsoft's Customer 
>>>Service office.  It's 3 pages long and defines the proposed market for both 
>>>programs.  Your assumption about the targeted markets is pretty close to 
>>>what Microsoft claims: Access - end user, Foxpro 2.5 - developer.
>
>>But that collides slightly with the fact that Microsoft is releasing
>>a distribution kit for Access at the end of January.
>
>	I don't know where you got this info. from.  When I
>	asked MS reps. in a MS Access seminar at Indy about its 
>	run-time distribution, they said MS will have Developer's 
>	Distribution Kit for FoxPro in Feb. (BTW, they were
>	demonstrating FoxPro at the same time), those two guys
>	didn't know whether MS has plans for an Access distribution
>	kit.

The Microsoft Access Distribution Kit will allow developers to write MS Access
applications and distribute them royalty-free.  It will be available
during the first half of 1993.  

Microsoft Access is targeted to end users, power users, and developers
who want a database that provides superior access to data and 
outstanding graphical tools for accessing and managing information. [Gosh,
I sound like a marketing guy.  I'm not, really!]  It is not just for end users!
With Microsoft Access version 1.0, distributing applications requires 
that the user of the application purchase a copy of Access.  The ADK 
will solve this problem.

	Andrew


Newsgroups: comp.databases.ingres
From: daveb@NREL.ColoState.EDU (Dave Bigelow 491-5574)
Subject: Optimizer question
Date: Mon, 28 Dec 1992 23:21:59 GMT
Organization: Natural Resource Ecology Lab, Colo. State Univ.

Using INGRES SunOS Version 6.4/02 (su4.u42/00) on a 670MP I get
the following message when I try to do a count by on a data field
(field_name). This also happens in Report_Writer when a conditional
on the field is specified.

   'the histogram for [field_name] is not monotonically increasing.'

In poking around I discovered that the table was re-optimized but
the second time without the inclusion of the offending field.  My
question is does the optimizer clear stale statistics each time it
is invoked or do I have to do another modify to clear the
statistics? Is this the likely cause of the problem?

Thanks for your reply.

-- 
Dave Bigelow                        
Natural Resource Ecology Laboratory  internet:  daveb@panicum.nrel.colostate.edu
Colorado State University            telephone: 303-491-5574      
Fort Collins, CO 80523               FAX:       303-491-1965
From: perl@dwrsun4.UUCP (Robert Perlberg)
Newsgroups: comp.databases.ingres
Subject: Re: Ingres Design Limits
Date: 22 Dec 92 21:44:26 GMT
Organization: Dean Witter Reynolds Inc., New York

In article <1992Dec9.235410.4228@goethe.credtech.com>, twombly@goethe.credtech.com (chris twombly) writes:
> I have heard that INGRES has some limitations, and amongst them:
> 
> -	30 table limit per database

Definitely false.  I've have databases with many more tables than
that.  Where did you get that from?

> -	2000 byte limit record size

True.  This also extends to joins.  The rows produced by a SELECT
cannot be more that 2000 bytes worth of data each, so you can't do
something like this:

	create table t1 (k1 integer, c1 char(1500));
	create table t2 (k2 integer, c2 char(1500));

	select c1, c2 from t1, t2 where k1 = k2;

The select will complain about the resulting row being too long, even
if you are not redirecting the output into another table.

> -	256 column limit per table

Probably true.  I've run into the 2000 byte limit myself (although if I
had my way I would have designed the database differently), but I'd
like to know what type of application would need more than 256
columns.

Robert Perlberg
Dean Witter Reynolds Inc., New York
dwrsun4!perl@murphy.com -or- philabs!dwrsun4!perl

"We don't believe the software industry is ripping off the customer."
	-- Ken Wasch, executive director of the Software Publishers Association
From: neidig@atonal.pci.upmc.edu (marty neidig)
Newsgroups: comp.databases.ingres
Subject: Re: ********
Date: 22 Dec 92 05:08:36 GMT
Organization: Pittsburgh Cancer Institute

Subject: Paradox and MS windows access to ingres 
Newsgroups:comp.database.ingres 
In-Reply-To:neidig@pci1.pci.upmc.edu 
Organization: Pittsburgh Cancer Institute



I am currently exploring the availability  and usefulness of various
tools to develop pc front ends by using tools such as
paradox and excel. Does anyone have any experience with such a project
and in particular using the Q+E client server products from Pioneer 
Software in conjunction with ingres net.


--Marty Neidig
Pittsburgh Cancer Institute             phone: (412) 647-6861
200 Meyran Ave                          email: neidig@pci1.pci.upmc.edu 
Pittsburgh PA  15213                          (internet)
Disclaimer: My opinions are my own and not those of my employer.
From: pavlov@niktow.canisius.edu (Greg Pavlov)
Newsgroups: comp.databases.ingres
Subject: Re: DB admin tools
Date: 29 Dec 92 16:18:28 GMT
Organization: Canisius College, Buffalo NY. 14208

In article <199212232117.AA13643@pony.ingres.com>, pneal@ingres.com (Calgary (Kal-gree), (403) 262-8119) writes:
> 
> If you have a copy of Ingres 6.4/02 you will find an application in the sig
> directory ($II_SYSTEM/ingres/sig) called schemadef_II.  It currently does what
> you are looking for ... altering a table and keeping all of its attached 
> objects.  The codeline will run against any 6.4 database.  If you haven't
> upgraded to 6.4 yet, maybe now is a good time?
> 
> Paul
> pneal@ingres.com

  From the "atop.hlp" file in that directory:

  "Alter(3)

   Allows for changing column names, datatypes, lengths, and null and default
   options on tables......  Does not preserve permits, grants, views, storage
   structures, or indexes."


  Am I missing something ?  (We are running 6.4)


  greg pavlov
  pavlov@fstrf.org
From: pneal@ingres.com (Calgary (Kal-gree), (403) 262-8119)
Subject: RE: DB admin tools
Organization: National Radio Astronomy Observatory
Date: Wed, 23 Dec 1992 21:17:36 GMT

Rob McNicholas wrote ...

>I'm working on a database which is in a constant state of flux.
>Necessity dictated that we put it into production before we had really
>worked out all the problems, so I often find myself dropping and
>recreating tables to add a new field, or change a field's size or
>type, etc.  After doing this once or twice, I quickly learned that
>there are many side effects of these kinds of changes.  For example,
>dropping a table causes any views, forms, or permits which referred to
>that table to be destroyed also, so the DBA needs to create scripts to
>recreate all the different pieces, and remember to update these
>scripts whenever a change is made anywhere.  Unfortunately, Ingres
>doesn't seem to provide any tools to help make this kind of change
>easier.  I've been using unloaddb and then editing the scripts to
>recreate just the parts i need, but this is tedious, and it doesn't
>handle forms or views very well.
>
>I've been thinking about writing my own tools that would access the
>system catalogs and help find all references to a particular table or
>field, so that these changes would be easier to manage.  But before I
>do it myself, I ask:
>
>Does anyone have any suggestions for any Public Domain or commercial
>products which would provide this kind of functionality?

If you have a copy of Ingres 6.4/02 you will find an application in the sig
directory ($II_SYSTEM/ingres/sig) called schemadef_II.  It currently does what
you are looking for ... altering a table and keeping all of its attached 
objects.  The codeline will run against any 6.4 database.  If you haven't
upgraded to 6.4 yet, maybe now is a good time?

Cheers,

Paul
pneal@ingres.com
Newsgroups: comp.databases.ingres