HDTenEightyP/NetNews huggingface dataset:
Organization: Rohm and Haas Company
Date: Wed, 12 Aug 1992 11:50:52 EDT
From: Randy Krail <RS0ORK@rohvm1.rohmhaas.com>
Newsgroups: comp.databases.ingres
Subject: Re: Naming conventions
 <1992Jul29.160529.1@gsbacd.uchicago.edu> <2792@perl-sun.dwrsun4.UUCP>

In article <2792@perl-sun.dwrsun4.UUCP>, perl@dwrsun4.UUCP (Robert Perlberg)
says:
>
>In article <1992Jul29.160529.1@gsbacd.uchicago.edu>, cs_mj@gsbacd.uchicago.edu
>(Mark Jaeger) writes:
>> ... Our table names are always
>> singular, so that the name defines what one row from the table is, not
>> the whole collection.  For example, the table that holds persons is
>> "gl_person", not "gl_persons".
>
>I've seen this convention used.  I'm interested in knowing what the
>rationale is behind it.  It seems to me that using the plural is more
>natural.  In all or at least most cases where you use a table name you
>are referring to the collection, such as in:
>
>        select * from gl_persons;
>
>Under what circumstances does the singular make more sense, and why do
>you consider it important enough to create what I consider to be an
>uncomfortable grammatical form in the most common usages?

We too use the "singular" naming convention.  This decision was based
on the following understanding:

As with Entity Types within an Entity-Relationship Diagram, a table
represents a class of data, not an instance of data.

Naming a table STUDENT implies that each record would relate to one
occurrence (or instance) of student.  Something that could be mapped
in the real-world to John Doe, student.  In using the plural (STUDENTS)
each record would relate to one instance of students.  In this case,
"students" would map in the real-world to occurrence of students such
as Freshman, Engineering Majors.

----------------------------------------------------------------------
Randolph S. Krail
Database Analyst
Rohm and Haas Company          E-Mail: rskrail@rohmhaas.com (Internet)
From: bleimeyr@mayo.edu (Bob Bleimeyer)
Newsgroups: comp.databases.ingres
Subject: Multiple database servers on a Sun 690
Keywords: servers, Sun 690 upgrade
Date: 12 Aug 92 16:46:20 GMT
Reply-To: bleimeyr@mayo.edu (Bob Bleimeyer)
Organization: Mayo Foundation, Rochester MN. Campus

We are currently considering the likely results of an upgrade to our Sun  
490 server to bring it to a 690 x 4 processor under SunOS 4.1.2.   This  
system serves two purposes at present. 1) Is the main backend database  
server for Ingres,  2) Is the central file server for distributed  
workstations requiring NFS service.   I am aware that certain types of  
applications actually perform worse using the Sun 4m processsor with Sun's  
current operating system.  

The question I have for the net is if anyone has experience with resolving  
the Ingres performance problems on a Sun 690 with any of the following  
approaches or some combination?

1) Multiple database engines on the same server.
2) Sun DBE 1.2 
3) Applying the current patches from Sun targeted toward 690 performance 
under SunOS 4.1.2

Please reply soon if you have some thoughts.  There is a bit of a time  
element here for us.

- Bob
-----------------------------------------------------
Robert R. Bleimeyer  	 Internet: bleimeyer@mayo.edu
Mayo Foundation
200 SW First Street
Rochester, MN 55905
------------------------------------------------------
Newsgroups: comp.databases.ingres
From: sfc@tpghq.com (Steve Caswell)
Subject: Re: Dynamic FRS
Organization: Palmer & Associates, Inc.
Date: Mon, 17 Aug 1992 22:16:59 GMT


From: ron@sigyn.cs.athabascau.ca (Ron Haukenfrers)
Newsgroups: comp.databases.ingres
Subject: Dynamic FRS

>Does anyone know of a way to dynamically create a field in an ingres form?
>I would like to create a field at runtime because it's datatype, length
>and attributes are all derived at runtime.  I guess I can use the old
>hack of creating a big text field and doing the manual type conversions,
>but that doesn't solve the problem of data length and attributes.
>
>
INGRES does not provide a way to do this.  It does give you a way for your
application to determine what fields reside on a form and build dynamic FRS
statements to manipulate the form.  The only way I know of to create a field
on a form dynamically is to monkey around with the ii_field system catalog,
which would be VERY messy.

-- 

Steve Caswell           |   (404) 448-7727    |  "The opinions expressed are my
Principal Consultant    |   sfc@tpghq.com     |   own.  They may not be perfect,
The Palmer Group        |   uunet!tpghq!sfc   |   but they're all I've got."
Newsgroups: comp.databases.ingres
From: S.C.Fitch@open.ac.uk (Steve Fitch K186 - 2733)
Subject: Source Control S/W
Organization: National Radio Astronomy Observatory
Date: Tue, 18 Aug 1992 17:25:44 GMT

Hi,

is anyone out there using source code control software with Ingres ?

We have looked at SCCS, although this seems anything but appropriate.
I would appreciate the view of others on this subject. Any product
suggestions would be useful.


Steve Fitch                            o          ,__o        o   /\/\
Open University                       <\        _-\_<,     []<\  /~~\ \/\
Management Services Division       ___/__,     (*)/'(*)      /> /    \ \ \
Milton Keynes, England.       +44 (0908)65 2733  s.c.fitch@open.ac.uk
From: alan@curta.cc.columbia.edu (Alan Crosswell)
Newsgroups: comp.databases.ingres
Subject: Re: IPM (and thanks)
Date: 18 Aug 92 14:59:36 GMT
Organization: Columbia University

In article <AA22211.199208171653.ttyB3@turing.ncl.ac.uk> Cristyn Emmett  
<Cristyn.Emmett@newcastle.ac.uk> writes:
> I have said to several people that we don't have IPM here with our
> Ingres 6.3/01.
> Well, I have recently discovered that we do (all the help files are
> empty, but the executable is there) so all I have to do now is sit
> down with the documentation and try to understand it :-)
> 
> I appreciate this group - so useful - just wish I could contribute
> a bit more.
> 
> Thanks to all you helpful people,
> 
> 	Cristy
> 
> Also known as:       
> cristyn.emmett@newcastle.ac.uk
> ******************************

There is an excellent tutorial on IPM and tuning written by the author
of IPM that he presented at our local Ingres user group meeting.  Perhaps
your Ingres rep can get you a copy:

	A Guide Tour using IPM
	Tom Turchioe
	Senior Consultant
	Ingres, a subsidirary of ASK Computer Systems, Inc.
Newsgroups: comp.databases.ingres
From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
Subject: Re: Full log file while doing deletes ?
Organization: 
Date: Thu, 20 Aug 1992 21:56:26 GMT

In article <1992Aug20.142018.11663@eagle.lerc.nasa.gov>,
dwolfe@halcon.lerc.nasa.gov (Dana Wolfe) writes:
>
> 	I have several large tables (  > 60MB ) from which I would
> 	like to delete about 15% of the rows. I continue to get the log
> 	file full error, and was wondering if there is a way aound this.
> 	The manual suggests increasing the size of the log file but,
> 	if I understand the instructions,  the size of the resulting log
> 	file seems unacceptable.

I believe the current party line from Ingres is to devote a whole disk
to the INGRES transaction log file, and then scale it back as you go
along if you find the space is wasted.  Ours is only 50 MB, but then, we
don't run a real OLTP shop.  It doesn't really matter _how_ big you make
the log file, because someone will always be able to come up with a
transaction that will fill it.

There are several things you could do to reduce the logging
requirements.

1. Use CAT (chunk-at-a-time) rather than RAT (row-at-a-time) operations
(credit to Derek Wright of Ingres for these names).  I.e., use:

	exec sql DELETE FROM t WHERE id BETWEEN 100 AND 200 ;

rather than

	for( kk = 100 ; kk <= 200 ; kk++ ) {
		exec sql DELETE FROM t WHERE id = :kk ;
	}

2. Use "set session with on_error = rollback transaction", which is new
in release 6.4.  If you really need to do RAT processing, this can
vastly reduce the logging requirements.  The only down side is that you
lose the ability to rollback a single statement (as opposed to the whole
transaction) or rollback to a savepoint.  I don't think I've met anyone
yet who cares about such partial rollbacks.

3. Break the delete into smaller pieces.  Use RAT processing, or SCAT
(small-chunk-at-a-time), and commit after each delete statement.

4. If you really get desperate, you can use "set nologging".  However,
be _very_ sure to read about this before using it.  If you use it, _any_
SQL error results in an inconsistent database which you will then have
to recover from a valid checkpoint.

5. Use "set log_trace" with some test cases for learning about all this
stuff.  It can give you a lot of insight into how INGRES does its work
and how these features work.

--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.
Ich bin ein Virus.  Mach' mit und kopiere mich in Deine .signature.
From: alan@curta.cc.columbia.edu (Alan Crosswell)
Newsgroups: comp.databases.ingres
Subject: Re: Silly question
Date: 20 Aug 92 14:19:36 GMT
Organization: Columbia University

In article <16vmkoINNdoj@fulmar.doc.ic.ac.uk> rsoc@doc.ic.ac.uk (Rob  
O'Connor) writes:
> Hi, as a relative novice user, I have a question. I have a column  
containing
> a unique number, the next row being 1 more than the previous, i.e
> 
> doc1
> doc2
> ..
> ..
> doc(n)
> doc(n+1)
> Is there a straightforward way to automatically update the next row as  
it's
> added by looking back at the previous maximum value? So when I append a  
row,
> Ingres looks back at the previous largest value and adds the next one by
> default?
> Apologies if it's a really stupid question, or I'm missing something  
obvious!
> BTW system is version 6.3 on SunOS 4.1.1.
> 
> Rob.
> -- 
> Internet: rsoc@doc.ic.ac.uk   Tel: +44 71 589 5111 x5070   Fax: +44 71  
581 8024

Not, not silly and a big pain.  If you are loading the table from a
program, use a program variable to increment the number.  For example:

   for (i = 0; xxx; i++) {
      ...
      exec sql insert into foo(docnum,blather) values(:i,:blather);
   }

A cheap trick that I use sometimes which is a total violation of
portability is to use the secret 'tid' (tuple-id) column on a heap
storage-structure table.  Heaps are just sequential, so I do stuff
like:

  modify foo to truncated
  copy foo(blather) from '....'
  update foo set docnum=tid

Then you can go ahead and modify foo to a different storage structure.

There is also a system-maintained datatype (another non-portable but
more acceptable feature of Ingres) where ingres explicitly manages the
row number for you.  See the SQL reference section of datatypes.

/a
Newsgroups: comp.databases.ingres
From: pneal@ingres.com (Calgary (Kal-gree), (403) 262-8119)
Subject: RE: Ingres on Solaris 2.0
Organization: National Radio Astronomy Observatory
Date: Mon, 17 Aug 1992 01:35:25 GMT

Horace,

Ingres  6.4/02 is currently certified for SUN/OS 4.1.2, and has been run 
'uncertified' against 4.1.3 (on a sparc10).  Solaris 2.0 support is expected
to be shipping by calendar year end `92.

Cheers

Paul

From:	PONY::"tjb@MATH.AMS.ORG" 15-AUG-1992 22:47:25.02
To:	info-ingres@MATH.AMS.ORG
CC:	
Subj:	Re: Ingres on Solaris 2.0

Hey:

Does anyone know if Ingres 6.4 runs/will run under Solaris 2.0?
If not, any idea if/when it will?

Horace
horace.bowser@txqis.amd.com
Newsgroups: comp.databases.ingres
From: WIELAND@USC.PPPL.GOV (Dick Wieland )
Subject: INGRES Forms and the Decterm Mouse (VAX/VMS)
Organization: National Radio Astronomy Observatory
Date: Wed, 12 Aug 1992 19:49:00 GMT

  I'm wondering whether anyone can help me cobble together a termcap
for INGRES Forms (V6.4/01 - VMS5.5) that can take advantage of all
three Vaxstation mouse buttons in a Decterm window under the Motif
Window Manager?

  Early on I was using the traditional "vt100f" termcap with Decterm,
with no mouse control over the cursor position, but with the usual
Decterm cut and paste features associated with mouse buttons (MB) 1 &
2.  By adding the vs= and ve= commands from the "decterm" entry
(vt240) I was able to come up with a modified termcap that allows me
to position the INGRES Forms cursor on any field in the form with the
mouse button, with a few limitations. It seems that no matter where in
the field I click the button, the cursor always goes to the beginning
of that field. In other words, there is no positioning capability
within the field itself. The annoying thing, though, is that the cut
and paste functionality of MB 1&2 is now lost; the cursor positioning
function is now supplied identically by all three mouse buttons!

If anyone has any ideas of how I can have my mouse and INGRES Forms
too, (i.e., MB1&2 for cut and paste, and MB3 for cursor positioning)
I'd love to hear from them.

Dick Wieland 
Princeton University
Plasma Physics Laboratory
Princeton, NJ 08543
609-243-3236

wieland@usc.pppl.gov
From: croft@csusac.csus.edu (Steve Croft)
Newsgroups: comp.databases.ingres
Subject: Transactions
Date: 13 Aug 92 22:22:10 GMT
Distribution: usa
Organization: California State University, Sacramento

When SQL statements update a database (before a commit statement),
is the database actually updated?  This would mean that the tx
log would hold info to rollback the changed info from the database,
right?

For some reason, I thought the tx log contained the new info, which
would update the database upon commit.  Can someone clarify?

Steve Croft
stevec@water.ca.gov
Newsgroups: comp.databases.ingres
Subject: how to add a new location ?
From: ofer@chen.bgu.ac.il (Ofer Reshef)
Date: Sun, 16 Aug 1992 17:35:27 GMT
Organization: Ben Gurion University, Beer Sheva, Israel

Hi All,
  I've tried to add a new db location using the AccessDb utility.
  But it didn't add a new location despite all my attempts.
  How do you add a new location ?
  I'm using ingres version 6 under ultrix 4.3 on a DecStation 5000.
  I'd appreciate any help.

         Thanks in advance,
              Ofer Reshef. (ofer@chen.bgu.ac.il)
Newsgroups: comp.databases.ingres
From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
Subject: <None>
Organization: 
Date: Sat, 15 Aug 1992 00:29:27 GMT

In article <BszJIK.Fyq@world.std.com>, jaa@world.std.com (Jerry A Abramson) 
writes:
> We are currently evaluating moving from Ingres 6.2 (part of the Open Dekstop
> 1.0 and 1.1 product) to Ingres 6.4.  There are numerous new features, bug fixes
> in 6.4 that we would like to take advantage of.  Before we begin the 
> transition, has any one out there already made the transition, and if so, any
> input would be greatly appreciated.

We're using INGRES 6.4/01 under VMS 5.5, but I think my comments are
still applicable.  INGRES 6.4 is the best version to date, and I'm just
talking about the base product--server and basic front end tools, all
enhancements and new features aside.  The product has gotten steadily
more robust.  We had nightmares working with 6.2; in fact, a planned
product rollout had to be delayed a year because of its instability. 
But 6.4 is much better.  Our move from 6.3/04 to 6.4/01 has been the
smoothest upgrade to date.  

> Additionally, we currently have some 6.2 Ingres code, I would assume we need
> to recompile with 6.4 libraries.  If anyone has experienced any problems with
> the new libraries or the 6.4 ESQLC preprocessor, input would be greatly 
> appreciated.

My guess is you'll have to recompile, or, even if you don't, it would be
a good idea.  My guess is also that the ESQL/C preprocessor hasn't
changed much, except to support the syntax for new features.  The
preprocessor has been one of the less buggy pieces.

> One last question, does Ingres support database rules (more than table-only
> integrity rules).  We are trying to embed the database rules within the db,
> not within the applications only.

Yes, but it's a separate product, part of the Knowledge Manager.  I
think the price is 30% of base, but check with your salesman.  

You can define as many rules on a table as you like.  You can ask that
each rule be triggered on insert, update, or delete (but not select). 
For update, you can specify particular columns only, if you choose.

When a rule is triggered by a DML, it causes the server to execute an
SQL database procedures.  You can pass in arguments, including any or
all of the old and new data, as appropriate.  DML changes within the
triggered procedures will trigger new rules, if applicable.  You can set
the depth to which they will cascade.

--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.
Ich bin ein Virus.  Mach' mit und kopiere mich in Deine .signature.
From: kmchylla@vms.macc.wisc.edu
Newsgroups: comp.databases.ingres
Subject: ESQL Bug
Date: 19 Aug 92 20:51:02 GMT
Organization: University of Wisconsin Academic Computing Center

We have Ingres 6.4 installed on two machines, the first being a
VAX 6610 (our production machine) and the second being a VAX
4000 VLC (our development machine) both running VMS 5.5.  Ingres
is installed separately on each machine.

I wrote an embedded SQL program using C that seems to go into an
infinite loop when I have too many records to process, and
I can't figure out why.  The program simply sets up a
cursor to read each record, take a character field (storing
a gregorian date) and convert it to a date.  It updates another 
field in the same record (a date field), and fetches the next record.   

This seems easy enough, but if my table gets too large it seems
to get "stuck" on a record and processes that same record until I 
stop the process.  The strange thing is, depending on the Ingres 
installation (production vs development) the program will run longer 
before looping.  (The production machine can handle larger tables 
than the development.)  

Our current work around for the problem is to chop the table into
smaller bits.  This seems to work, but I'd love to know what the
real problem is.  Ingres never gives us an SQL error or VMS
error message to track so we have decided it is not in our code
or data.

I figure the problem is in an Ingres buffer somewhere since the
two installations are very different.  One is set up to accomodate
our whole site, and the other to accomodate a few developers.  I
am hoping that someone out there knows an Ingres or system
parameter that I can modify to allow the query to work on both
machines.

My internet address is km.chylla@hosp.wisc.edu

Thanks in advance for your help!
From: kerry@Ingres.COM (Kerry Kurasaki)
Newsgroups: comp.databases.ingres
Subject: Re: Transactions
Date: 14 Aug 92 18:53:19 GMT
Article-I.D.: pony.1992Aug14.185319.118
Reply-To: kerry@Ingres.COM (Kerry Kurasaki)
Distribution: usa
Organization: Ask Computer Systems Inc., Ingres Division, Alameda CA 94501

In article <1992Aug13.222210.22657@csusac.csus.edu> croft@csusac.csus.edu (Steve Croft) writes:
>When SQL statements update a database (before a commit statement),
>is the database actually updated?  This would mean that the tx
>log would hold info to rollback the changed info from the database,
>right?
>
>For some reason, I thought the tx log contained the new info, which
>would update the database upon commit.  Can someone clarify?
>

What is actually in the database file is indeterminate during/after
an update.

This may sound confusing, but the buffer cache has the 'latest'
information in it and is not necessarily flushed to disk if fast_commit
is running.  Everyone (locking contention aside) sees the buffer
manager's version so there is no problem.

The transaction log file contains sufficient information to reconstruct
the database page if the system should fail.  That is, if the page
got flushed back to disk and the transaction was not commited, the
transaction log has the before image information to undo the transaction.
In addition, if the page was NOT flushed to disk at commit time and
the system failed, the transaction log file has sufficient information
to redo the transaction.

The transaction log file is always flushed to disk before a commit
is acknowledge to the session.

OK?

Kerry
Newsgroups: comp.databases.ingres
From: "Warren Spencer (315) 349-0493" <EV2WS1%MISX01@KINGSTON.ARPC.ALCAN.CA>
Subject: Re: Form-/menu-based PC frontends to DBs
Organization: National Radio Astronomy Observatory
Date: Thu, 20 Aug 1992 13:56:00 GMT

>Does anyone have suggestions for forms- or menu-based PC client
>software that can be used to query Ingres DBs running on a server
>using Ingres/Net?  

>Possibilities are IQ, which won't come out with an Ingres compatible
>version for another month, and maybe SQL Assist.  Does anyone have
>any experience with these or similar?

>Seth Grimes, dcatlas!sethg@uunet.uu.net

Hi Seth,

We use SQL Assist for ad-hoc users queries.  It is Vax based, although we will 
be pursuing a PC-based version soon.  It's a good product for users that never 
ask for the same data twice!

Warren Spencer
Ingres Specialist
InCAD Corporation
Ottawa, Canada.
(613) 723-5452

Newsgroups: comp.databases.ingres
From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
Subject: Re: Cursors & embedded SQL
Organization: 
Date: Sat, 15 Aug 1992 01:52:18 GMT

In article <24464.9208131114@subnode.bradford.ac.uk>, A.Hobson@bradford.ac.uk 
(Andy Hobson) writes:
> 	I want to create a switch() in C which has approximately 25 cases,
> 	each with a different DECLARE CURSOR FOR SELECT ....
> 	But I want to use the same FETCH statement for all the cursors I have
> 	created as they all produce the same number & type of columns. 

As you suspected, the answer lies in dynamic SQL.  It's not as bad as it
looks, and the reason is that you already know what the output of each
SELECT looks like (they can all be handled with the same FETCH). 
Dynamic SQL is difficult only when you _don't_ know what the output
columns are.  In this latter case, you have to use DESCRIBE (or
PREPARE...INTO) and the SQLDA, which can be pretty messy.

In any case, I have attached some sample code that illustrates the
technique.  It's written in ESQL/C.  You'll have to change your switch
somewhat.  The body of each case should contain the text of the SELECT,
and not a DECLARE CURSOR statement.  All you have to do is set a string
variable to this text, and away you go.  

The trick is to use the dynamic form of the "declare cursor" statement,
which necessitates using the "prepare" statement before opening the
cursor.  If your SELECT statement contains program variables in the
WHERE clause, you can still use "sprintf" to create a fixed text string;
or replace the variable with "?" and put a USING clause on the OPEN
statement.  See the SQL Reference Manual for details.

--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.
Ich bin ein Virus.  Mach' mit und kopiere mich in Deine .signature.

================================================================================
exec sql INCLUDE sqlca ;
exec sql WHENEVER sqlerror call sqlprint ;
exec sql WHENEVER sqlwarning call sqlprint ;

#include <stdio.h>
#include <stdlib.h>

/*++*/ int main( int argc , char *argv[] ) {
	exec sql BEGIN DECLARE SECTION ;
	char *stmt ;
	char buf[ 80 ] ;
	exec sql END DECLARE SECTION ;
	int switch_value = atol( argv[1] ) ;

	switch ( switch_value ) {
	case 1 :
		stmt = "select distinct table_owner from iitables" ;
		break ;
	case 2 :
		stmt = "select distinct table_name from iitables" ;
		break ;
	default :
		exit( EXIT_FAILURE ) ;
	} /* end of switch */

	printf( "Connecting..." ) ;
	exec sql CONNECT 'iidbdb' ;
	printf( "done.\n" ) ;

	exec sql DECLARE my_stmt STATEMENT ;
	exec sql DECLARE my_cur CURSOR FOR my_stmt ;

	printf( "Opening cursor for statement %d:\n%s..."
		, switch_value , stmt ) ;
	exec sql PREPARE my_stmt FROM :stmt ;
	exec sql OPEN my_cur FOR READONLY ;
	printf( "done.\n" ) ;

	while( 1 ) {
		exec sql FETCH my_cur INTO :buf ;
		if ( 0 != sqlca.sqlcode ) break ;
		printf( "%s\n" , buf ) ;
		} /* end of while */

	exec sql CLOSE my_cur ;

	exec sql DISCONNECT ;

	} /* end of main */