HDTenEightyP/NetNews huggingface dataset:
From: jde@Unify.com (Jeff Evarts)
Newsgroups: comp.databases
Subject: Re: 500'000 records - who does best?
Date: 5 Jan 93 18:09:00 GMT
Organization: Unify Corporation (Sacramento)

In article <brent.725766347@cc.gatech.edu>, brent@terminus.gatech.edu (Brent Laminack) writes:
> 
> >I believe that this thread started out as a "can anyone do this REASONABLY"
> 
> >UNIFY 2000 can handle this (500K rows @ 30K per row). If you have the disk space,
> >we have the database. :-)
> 
> >Mischa is right... its not the users, it's the size of the database. The
> >UNIFY 2000 database package can have individual table segments in the 16+Mb
> >category, allowing over 500 rows per segment, so the table would only require
> >10000 segments.
> 
> Is this the same Unify company that tells me to try to keep all tables
> to 16 or fewer segments? After that performance is said to degrade? If
> memory serves, 10000 >>> 16

Cute... but

Performance _can_ degrade by one _virtual_ read per row access IF:

	1. You have more than 16 segments in a table, AND
	2. You are short on ram, AND
	3. The row requested is not in a recently used segment.

On a system wanting to keep 1.5TB of data

	1. A lack of RAM is not likely.
	2. Other latencies will overshadow the additional read.

So it should not be a problem.

> 
> >You would still have plenty of room for indices and the rest.
> 
> >Performance is impossible to judge without getting your hands a little dirty.
> >It depends on hardware, access patterns, indexing strategies, and a whole lot
> >more, but in general UNIFY 2000 is very hard to beat in the performance area.
> 
> There are other considerations, however. Ask Unify to do an outer join.
> They can't.

Hmmm. not _strictly_ true. There are many ways to do this in UNIFY, from within
SQL and out. We do not have a DIRECT mechanism to do this because we try to be
ANSI SQL compliant and ANSI SQL uses UNIONs to do what other database companies
use outer joins to do. So although we do not have a nifty way to do this directly,
you can get the job done (often more efficiently) by taking other routes.

> 
> No brag, just facts.
> 
> Brent Laminack (brent@cc.gatech.edu)
> 
> 
> 					
> 					-Brent Laminack (brent@cc.gatech.edu)

Really, though. The base conversation was "can anyone handle this", and
"can they handle it REASONABLY". The answer is still yes to both questions.

Disclaimer: I'm a techie, not a sales-ie

-Jeff Evarts
--jde@unify.com
---#include <sys/disclaimer>
Newsgroups: comp.databases
From: rao@cs.mu.OZ.AU (Kotagiri Ramamohanarao)
Subject: 2nd call for papers for VLDB Special Issue
Originator: rao@munta.cs.mu.OZ.AU
Reply-To: rao@cs.mu.OZ.AU (Kotagiri Ramamohanarao)
Organization: Computer Science, University Of Melbourne, Australia
Date: Tue, 5 Jan 1993 04:11:16 GMT



				2nd Call for Papers


The VLDB Journal:  Special Issue on Prototypes of Deductive Database Systems



The VLDB Journal is planning a special issue on Prototypes of Deductive
Database Systems. Potential authors are encouraged to submit original
papers describing prototype deductive database systems. Papers should
address the issues below.


  o Query and Update Language Description

  o Computational Model

  o Optimisation Techniques

  o Implementation and System Architecture

  o Performance Measurements

  o Applications


Potential authors are encouraged to submit original, journal quality papers
to the special issue editor.


      Professor Kotagiri Ramamohanarao          Fax: +61 3 282 2444
      Department of Computer Science            E-Mail: rao@cs.mu.oz.au
      University of Melbourne
      Parkville, 3052
      Victoria, Australia



  Send 6 copies of a complete manuscript of no more than 35 type-written, 
double-spaced pages.  For more specific information see the Guidelines 
for Manuscript Preparation of the VLDB Journal which can be obtained through 
the special issue editor or the responsible editor-in-chief Hans J. Schek
(schek@inf.ethz.ch). All papers will be reviewed through the Journal's
editorial board.

Important dates:


     March 1, 1993            Due date for manuscript
     June 1, 1993             Notification of acceptance
     August 1, 1993           Due date for final revised version


A preliminary statement of your intention to submit would be appreciated.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Prof. Ramamohanarao Kotagiri                              rao@cs.mu.OZ.AU
Department of Computer Science                         FAX +61 3 348 1184
The University of Melbourne                            Ph. +61 3 344 5230
Parkville, 3052
AUSTRALIA

Newsgroups: comp.databases.ingres
From: drcoles@somnet.sandia.gov (Dwight R Coles)
Subject: Shared Memory Address Bug, Ingres on Sun 4.1.3
Organization: National Radio Astronomy Observatory
Date: Thu, 7 Jan 1993 19:43:02 GMT

Sorry if you on the list have already heard of this bug, but since
I've been off of it for two months, I don't know if it has been
discussed.  Anyway....

Ingres (ver 6.4/02/00) fails to iistartup properly on Sun 4.1.3
due to a bad shared memory address.  This bug popped up at 4.1.3,
as things were OK under 4.1.2 and earlier.  You will recognize it
by the following output from the step in iistartup which 
"allocates shared memory":

!shmat for id 102 at address F4000000 fails
!errno = 22
!Can't map locking segment into memory at address FFFFFFFF
!Check or adjust the value of II_LG_MAP_ADDR.....

To fix this, set the Ingres variable II_LG_MAP_ADDR to 10000000.
Example:

	ingsetenv II_LG_MAP_ADDR 10000000

You will probably want to stick this line into the rc or the rc.local
file immediately before the "su ingres...." line.



A second bug which we found on the Ingres 6.4/02/00 tape for Suns is 
that the ingres/files/iishutdown file is in compressed form (.Z).  If
you are doing a new install, there is no iishutdown available when
iibuild tries to do it (the iishutdown step occurs BEFORE the uncompress
step).   Thus, after reading the tape, you may want to:

   cd utility
   uncompress iishutdown.Z
   cd ..

On updated installs, you simply get to use the old version of iishutdown
to shut down any old versions of Ingres back-ends (which is fine).  Then
the uncompress command overwrites the iishutdown file with a new copy.

Later - Dwight Coles      drcoles@sandia.gov

Newsgroups: comp.databases.ingres
From: coop@panix.com (Robert Cooper)
Subject: Re: Running Ingres using Unix Cron
Keywords: Ingres Cron
Organization: PANIX Public Access Unix, NYC
Date: Wed, 13 Jan 1993 03:00:52 GMT



>I have been trying to run an Ingres report using the unix Cron
>facility so that some report files can be automatically updated on a
>daily basis.  I use the report <database> <reportname> feature of
>ingres inside of an executable unix script.  If I run this script
>manually it works correctly.  If I set this up as a Cron job it does
>not work even when I preface all files with appropriate paths.  Since
>others have had problems making ingres programs (e.g. embedded SQL and
>4GL) run under Cron I wanted to find out if there is a way to make
>this feature work.  If the job cannot be run automatically the
>usefulness of the ingres report writer goes to zero in this
>application.  I would appreciate any help on this matter.  Thankyou.

>Carl Bignell


Cron uses a very limited path when it runs. Ingres needs to find other
files in its bin directory. At the top of your shell script you need
to include the ingres/bin directory to the default cron path.


-- 
Robert Cooper  Brooklyn, NY | "We have to learn to manage information and 
coop@panix.com              |  its flow. If we don't, it will all end up 
212 309-9600 (Work)         |  in turbulence." Grace Hopper
From: barr@stein.u.washington.edu (David Barr)
Newsgroups: comp.databases.ingres
Subject: adding private ingres-net authorizations
Date: 5 Jan 93 20:29:48 GMT
Article-I.D.: shelley.1icr3sINNgg5
Organization: University of Washington
NNTP-Posting-Host: stein.u.washington.edu

I want to automate the addition of new users to our ingres net
authorizations.  Is there any alternative to using "netu" to do this,
like an "ii" table of some sort that I can modify?

David
Newsgroups: comp.databases.ingres
From: Tom Davies <tomd@horse.demon.co.uk>
Subject: Q: How to get dates as DD/MM/YYYY?
X-Xxmessage-Id: <A7779A728C0108B0@horse.demon.co.uk>
X-Xxdate: Mon, 11 Jan 93 21:43:14 GMT
Organization: None
X-Useragent: Nuntius v1.1.1d16
Date: Mon, 11 Jan 1993 21:44:01 GMT

Is there any way of getting values from a date column in the format 
'dd/mm/yyyy', i.e. *with* the century, without messing around with 
date-part?
Thanks,
	Tom
---------------------------------------------------------------------
        Tom Davies - 14 Rotterdam Drive, London E14 3JA, 071 987 0392
                   - tomd@horse.demon.co.uk

 -----PGP 2.0 PUBLIC KEY AVAILABLE-----
---------------------------------------------------------------------
Newsgroups: comp.databases.ingres
From: mdchaney@fractal.ucs.indiana.edu (M Darrin Chaney)
Subject: Re: Encryption
Organization: Indiana University, Bloomington
Date: Mon, 11 Jan 1993 20:08:14 GMT

In article <1993Jan8.170939.9261@advtech.uswest.com> crb@advtech.uswest.com (Chris Renck) writes:
>We are developing a application which is going to contain salary information,
>and I was wondering if anyone has any suggestions on how the salary field
> can be encrypted or secure so only authorized people can see it.  Our Human 
>Resources Dept does not even wants us (the Ingres developers) to be able to
>see what data is in this field.
>
>If anyone has run across this situation and/or has any suggestions, it would
>be greatly appreciated.
>
>The application is on Windows 4GL(2.0/01-su4.u42/00) and we are running it on a Sun 4/490 (SUN OS 4.1.1)i

Salary information is open information at most firms.  You should find out
*why* your human resources department is so worried about you seeing it...

	Darrin
-- 

mdchaney@iubacs mdchaney@bronze.ucs.indiana.edu mdchaney@rose.ucs.indiana.edu

"I want- I need- to live, to see it all..."
Newsgroups: comp.databases.ingres
From: frank@Ingres.COM (Frank Geick - INGRES/ADVISOR x3558)
Subject: Re: Tech Support
Reply-To: frank@Ingres.COM (Frank Geick - INGRES/ADVISOR x3558)
Organization: Ask Computer Systems Inc., Ingres Division, Alameda CA 94501
Date: 13 Jan 93 03:39:44 GMT

In article <1993Jan11.151431.19455@macc.wisc.edu> ninab@zucchini.macc.wisc.edu (Nina Boss) writes:
>I'm just wondering is ingres advisor still available by telnet to  
>advisor.ingres.com?  Is tech support available this way?  Thanks.

Advisor has been available via telnet to qualified (eg wrt Internet
Appropriate Use Policy) sites since Q3 1992. If you have an Advisor
account and have trouble connecting please contact Technical Support.

If you have an active INGRESplus support license (which includes Advisor)
the TSconnect facility within Advisor will enable communication with the 
North American Ingres Technical Support organization. The TSconnect 
facility will allow you to open "calls" and display the status and 
transaction history of any call you have placed (by voice or on-line, 
back to August 1989), plus any knowledge base documents used to address
each call.  [Handy if you later forget the solution].

Users which purchase "Advisor only" support licenses can search the
Tech Support organization 12,000 document on-line internal support
Knowledge Base ("KAT") or any of the 49 product news groups in the 
BBS, but will not have access to the TSconnect facility.

The January Advisor system update is being installed this weekend. 
TSconnect will allow license based reporting, enhanced two-way 
communication, and several other SIRs requested by users. Also,
the new "SendDOC" feature will enable users to FAX or email any
knowledge base documents, call documents or BBS items to their
site.

We are completing the work to allow (CIX, CO+RE, ERS) commercial routing 
through the Internet to Advisor. We are looking for sites to beta test the 
commercial routing. Please contact frank@ingres.com

-----------------------------------------------------------------------------
Frank Geick
Manager, Knowledge Base Systems
Ingres Corporation                               frank@ingres.com
Alameda, California                              510.748.3558
-----------------------------------------------------------------------------
Newsgroups: comp.databases.ingres
From: RVBAAL@kub.nl (Reinier van Baal)
Subject: Re: DB admin tools
Date: Wed, 06 Jan 93 08:03:33 GMT
Organization: Tilburg University (KUB)
X-News-Reader: VMS NEWS 1.22

In <1993Jan5.190338.23433@pony.Ingres.COM> 
   billc@Ingres.COM (Bill Coffin, at Ingres) writes:

[.... part of discussion deleted]

> 
> My reccomendation to Rob McNicholas, the original poster, would be to
> use views liberally while developing the applications.  You can use
> many tricks to avoid the necessity of redefining tables.  You will,
> of course, pay a performance penalty, but that may be acceptable in
> your Beta phase.
> 

One is tempted indeed, to solve this problem using an private, fixed-named
view, e.g. create a temporary table with a variable user dependant name, and
then a (temporary) view, having a fixed name. So you can use repeated inserts
without hard-coding tablenames, it looks.

But beware: QEP's of repeated queries are stored in the server (translating 
the view definition of its first occurrence). Another user subsequently
issuing the same repeated insert (after having created his own view) uses
this same qep, and will try (in vain of course) to insert into the temporary
table that is owned by the user whose qep is stored in the server.

> -- 
> Bill Coffin, at Ingres, An ASK Company, Alameda CA 
> billc@ingres.com	510.748.3387
> <standard_disclaimer> <gratuitous_witticism> <obscure_quote> <annoying_graphic>
 
 ----------------------------------------------------------------------
 Reinier van Baal,                             
 Tilburg University, Holland                   internet: rvbaal@kub.nl    
 (Katholieke Universiteit Brabant)             phone: +31 (0)13-66 2459   
Newsgroups: comp.databases.ingres
From: billc@Ingres.COM (Bill Coffin)
Subject: Re: DB admin tools
Reply-To: billc@ingres.com
Organization: Ingres, An ASK Company, Alameda CA
Date: 12 Jan 93 22:14:29 GMT

In article <1993Jan11.135316.1@gsbacd.uchicago.edu>, cs_mj@gsbacd.uchicago.edu (Mark Jaeger) writes:
>
>Maybe we're just quibbling about apples and oranges, but I thought that
>"system catalog" meant anything that is in an empty, newly-created
>database.  At least, that's what it meant in version 5.  I think it
>might be more correct to say that "iidbdepends" is not part of the
>Standard Catalog Interface, but rather it is an internal dbms system
>catalog, for INGRES internal use only.  

Right.  There is an arcane terminology here.  My understanding is
that the "System Catalogs" are documented, in 6.4, in an appendix of
the SQL Reference Manual.  Our guarantee is that these catalogs will
never disappear, that no column will ever change or disappear.  We
reserve the right to add new columns, or to increase the length of a
character column.  So don't ever fetch into a struct, fetch into
individual variables (which can be struct members) explicitly.
iidbdepends is not documented in the SQL Reference Manual, so our
guarantees do not apply to it.  However, it is completely safe to
rely on, say, iitables, as long as you program with a little
caution.

>> My reccomendation to Rob McNicholas, the original poster, would be to
>> use views liberally while developing the applications.  You can use
>> many tricks to avoid the necessity of redefining tables.
>
>Bill's suggestion doesn't speak to most of the reasons that I need to
>drop and recreate a table: adding a column; making a column longer; and
>renaming a column.  That we do this so frequently is probably due to a
>flawed development process, with an inadequate analysis and design
>phase, but the fact remains that we users _do_ have to change our tables
>from time to time.  The copydb tool has long been inadequate to the
>task, really since version 6, when INGRES first started dropping views
>when you drop a table.

I don't mean to offer an excuse.  I certainly believe we should do
better at supporting table changes.  And there are many requirements
that cannot be handled by "tricks".  However, in a development 
environment a trick can sometimes save you a lot of trouble.  Yes,
ALTER TABLE would be better, but I have seen instances where a
column can be added by creating a view and joining to a second table.
Slower, but it's a development environment.  COPYDB of all of the user's
objects will recreate dependencies, so you can COPYDB, edit the copy
script, and reload.

Also, I think in general that it's a good policy to implement a
schema so that applications access it entirely through views.  This
makes it easier to change the schema by twiddling the views.
(Although this gets problematic, for example when your updates fail
because an altered view becomes non-updateable.)  When you "go
production", you switch to real tables.

-- 
Bill Coffin, at Ingres, An ASK Company, Alameda CA 
billc@ingres.com	510.748.3387
<standard_disclaimer> <gratuitous_witticism> <obscure_quote> <annoying_graphic>
From: al439@cleveland.Freenet.Edu (David Churnega)
Newsgroups: comp.databases.ingres
Subject: Subscription comp.databases.ingres
Date: 9 Jan 1993 12:05:24 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: slc10.ins.cwru.edu


How do I enter my address in the mailing list so that I get regular
mail in this area?
Newsgroups: comp.databases.ingres
From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
Subject: Re: adding private ingres-net authorizations
Organization: 
Date: Mon, 11 Jan 1993 22:22:12 GMT

In article <1icr3sINNgg5@shelley.u.washington.edu>, 
barr@stein.u.washington.edu (David Barr) writes:
> I want to automate the addition of new users to our ingres net
> authorizations.  Is there any alternative to using "netu" to do this,
> like an "ii" table of some sort that I can modify?

INGRES/Net authorizations are stored in some special funny files in
ii_system:[ingres.files.name] (VMS only).  The files are called
iilogin_<nodename>.  Try displaying them with VMS "dump" (or UNIX "od"). 
You might be able to hack the files and add data to them directly, but I
wouldn't recommend it.  If you take this approach, make sure that you
shut down the net server before changing the file.

There is no system catalog you can change, because INGRES/Net doesn't
depend on a database or a database server.  You can have a net-only
installation.

A better solution would be to fox INGRES into thinking you are the other
user by changing your username.  Look in ii_system:[ingres.sig.setuser]
for a program that allows you to change the username under VMS.  Then
run netu and create the user authorization, and voila.  INGRES only
looks at the VMS username to determine who you are.  This can be
automated, too, by using a program to write a script, and giving this
script as the input to netu.  

It really works.  I know, I've tried it.

--Mark Jaeger				internet: cs_mj@gsbvax.uchicago.edu
Graduate School of Business		yellnet:  (312) 702-0328
University of Chicago			faxnet:   (312) 702-0233
Disclaimer: My opinions are my own and not those of my employer.
Je suis un virus.  Prends ton pied et copie moi a ta .signature.

Newsgroups: comp.databases.ingres
From: mmr@asgserver.canberra.edu.au (Micheal Rainford-Watson)
Subject: Re: Help - ABF/4GL questions.
Organization: University of Canberra
Date: Thu, 7 Jan 93 04:47:14 GMT

In article <00966285.BBAC44C0.3043@hal.hahnemann.edu> "Anthony J. Rzepela" <rzepela@hal.hahnemann.edu> writes:
>In response to a messy locking situation where the user
>GOLD@ILP.MIT.EDU (Mark D. Gold) wanted to avoid deadlock on 
>a shared resource (a temporary table), it was pointed out 
>by Mark Jaeger <cs_mj@gsbvax.uchicago.edu> that
>
>1> ABF has a neat lock detection and deletion feature.
>
>2> User-interrupts are not easily handled in the 4GL. 
>
>In relation to the first matter, I have had the experience where
>an interrupted (^Y, ^C) session of ABF still exists as a lock, 
>as the locks from these "dead" sessions show up until explicitly 
>deleted by the new ABF user.  (I am at 6.3/03 on VMS 5.4-2). 
>
>What would be really slick (and I don't know about feasibility)
>would be to include in the application a user-maintined lock system, in which 
>the application desiring a resource could check not only for one of these
>pseudo-locks, but also, if found, the status of the process that created it.
>(Is it still running, in a PFW, etc.?) 

... keep going ..

And if the resource is being held by a user (for too long), they are 
informed that someone is waiting for that resource and they should
'get on their bike!'.

-- 
Micheal Rainford-Watson        _--_|\   E-Mail: mmr@asgserver.canberra.edu.au
Administrative Systems Group  /      \  Phone : +61 6 201 2397
University of Canberra        \_.--.*/  Mail  : PO Box 1 BELCONNEN ACT 2616
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^v^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Newsgroups: comp.databases.ingres
From: camidei@Ingres.COM (Chris Amidei)
Subject: Re: How to display 132-character lines?
Organization: Ingres, an ASK Company, Alameda CA 94501
X-Newsreader: Tin 1.1 PL3
Date: 12 Jan 93 01:54:11 GMT

The width of screens is a part of a terminals definition found in TERMCAP.
For some terminals, there will be a 'WIDE' and 'NARROW' version of the terminal.

For example: A DEC vt220 has a TERM_INGRES setting of vt220.  This will be an
80 character wide screen.  If you would like 132 column mode display then use
vt220w (for wide) as the value of TERM_INGRES.

For some terminals (like vt220's) there are TERMCAP entries that allow
applications to change between narrow and wide on the fly.  Look through

$II_SYSTEM/ingres/files/termcap   in Unix or
II_SYSTEM:[INGRES.FILES]TERMCAP.  in VMS for more posibilities.

--
Nga hi bin doe?  Nga hi bin gaw?   Why am I speacking Bad Chinese??????
------------------------------------------------------------------------
Chris Amidei		| E-mail: camidei@ingres.com
Instructor        	|  Phone: (510)748-3261 - my desk
Ingres, an Ask Company	|       : (510)769-1400 - main line
Newsgroups: comp.databases.ingres