HDTenEightyP/NetNews huggingface dataset:
From: efk@po.CWRU.Edu (Edward F. Kerekes)
Newsgroups: comp.databases.ingres
Subject: Printer Problems
Date: 19 Aug 92 19:22:47 GMT
Reply-To: efk@po.CWRU.Edu (Edward F. Kerekes)
Organization: Case Western Reserve University, Cleveland, OH (USA)


I need some help or suggestions.  We just installed Ingres 6.4 on a machine
running SCO Unix.  Everything is fine and dandy except I can't send reports
directly to the printer.  I tried the report writer, inside applications, and
print screen in the RBF.  The error I get E_RW13ED tells me there is a 
problem printing the file /usr/ingres/file and that the error is
caused by an invalid ptinter or system error.  I can print in the Unix
environment.  I searched the manuals and could not find a list of printers
or where I can change the default printer or where I set the default printer
to begin with. Has anyone else ever had this problem?  I tried changing
ING_PRINT locally and this had no effect.

Any help or suggestions is greatly appreciated.
-- 
    Edward Kerekes   Case Western Reserve University,  Pediatrics-CMIS
"Some Days You get the bear,
 Some Days the bear gets you."
				efk@po.cwru.edu
Newsgroups: comp.databases.ingres
From: aims_elena@gsbacd.uchicago.edu
Subject: CASE tools for INGRES?
Organization: 
Date: Wed, 12 Aug 1992 22:42:52 GMT



I'm wondering if anyone has used CASE tools with INGRES, and what your
experience has been.  I will be glad to post a summary of replies.
Thank you very much!

Elena M. Yatzeck
Graduate School of Business
The University of Chicago
aims_elena@gsbvax.uchicago.edu
From: ccwilfred@uqvax.cc.uq.oz.au
Newsgroups: comp.databases.ingres
Subject: error check in proc rules
Date: 18 Aug 92 15:24:55 AEST
Organization: University Of Queensland

Is it true that the IF statement and the RAISE ERROR in the code below will
never be executed if it is in a procedure which is only executed by a rule?

    INSERT INTO unique_key_tbl VALUES (1234,'data');
    INSERT INTO unique_key_tbl VALUES (1234,'data');  /* do it again */
    IF iierrornumber != 0 THEN
       saved_error_number = iierrornumber;
       err_msg = 'This code will never execute if proc called by rule';
       RAISE ERROR :saved_error_number :err_msg;
    ENDIF;

Is there any reason for checking the value of iierrornumber after a 
database command in procedures fired by rules?  I expect not, I want to 
be very sure before I refuse to code such checks.

Cheers  -  Wilfred Brimblecombe            wilfred@cc.uq.oz.au
           Prentice Centre
           The University of Queensland
           Brisbane
           Australia.
From: anders@cmdsf.UUCP (Anders Nicolausson)
Newsgroups: comp.databases.ingres
Subject: Re: Printer Problems
Summary: A fix
Date: 20 Aug 92 16:23:04 GMT
Organization: Construction Market Data, Inc.

In article <1992Aug19.192247.16118@usenet.ins.cwru.edu>, efk@po.CWRU.Edu (Edward F. Kerekes) writes:
> 
> I need some help or suggestions.  We just installed Ingres 6.4 on a machine
> running SCO Unix.  Everything is fine and dandy except I can't send reports
> directly to the printer.  I tried the report writer, inside applications, and
> print screen in the RBF.  The error I get E_RW13ED tells me there is a 
> problem printing the file /usr/ingres/file and that the error is
> caused by an invalid ptinter or system error.  I can print in the Unix
> environment.  I searched the manuals and could not find a list of printers
> or where I can change the default printer or where I set the default printer
> to begin with. Has anyone else ever had this problem?  I tried changing
> ING_PRINT locally and this had no effect.
> 
> Any help or suggestions is greatly appreciated.
> -- 
>     Edward Kerekes   Case Western Reserve University,  Pediatrics-CMIS
> "Some Days You get the bear,
>  Some Days the bear gets you."
> 				efk@po.cwru.edu

I have a quick solution for you. INGRES uses, apparently hardcoded(!),
/usr/bin/lpr to print, so you have to replace your existing lpr
with a script as follows:
-------------------------------------------------------------

:
#	/usr/bin/lpr
#
#	This script is a fix for handling INGRES printing
#

#	Replace lpr-style option arguments with equivalent
#	lp options
options=`echo $* | sed -e "s/-P/-d/; s/-#/-n/; s/-J/-t/"`

lp -ow $options

-------------------------------------------------------------

This will work fine, as long as you don't need to explicitly
change the lp options, in which case you have to hack some more.

Anders Nicolausson
CMD, San Francisco
Newsgroups: comp.databases.ingres
From: Tracey Westbrook <twestbrk@thama1.apgea.army.mil>
Subject: FRS fields
Organization: National Radio Astronomy Observatory
Date: Tue, 18 Aug 1992 12:59:13 GMT

>
>> 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.
>
>This question has certainly come up before, and the sad answer is...no. 
>With standard character-cell-based FRS, you just can't do it.  You might
>be able to reverse engineer the forms system catalogs (ii_object,
>ii_forms, ii_fields, and ii_trim), and create a form on the fly that
>way, but it's probably a whole lot of work and not certain to succeed.
>
>You can do quite a bit with SET_FRS (or SET_FORMS in 4GL).  You can
>change many of the field attributes on the fly.  Another possibility
>would be to have a form with a stock of fields of varying sizes and
>types.  If they were all invisible by default, then you could visibilize
>the one you want at run time.  Disadvantage: they show up at different
>places on the screen.

Another idea may be to create a small pop-up form for each feild, and call
the form that has the needed datatype on it.

-*-*-*-*-*-*-*-*-*-*--*-*-*-*-*-*-*-*-*-*-*-*-
Tracey Westbrook
twestbrk@thama1.apgea.army.mil (Internet)
U.S. Army Toxic and Hazardous Materials Agency
Aberdeen Proving Grounds, Maryland, USA
Telephone: 410.679.3030   
FAX      : 410.676.0802  
-*-*-*-*-*-*-*-*-*-*--*-*-*-*-*-*-*-*-*-*-*-*-
Newsgroups: comp.databases.ingres
From: pneal@ingres.com (Calgary (Kal-gree), (403) 262-8119)
Subject: RE: reportwriter question
Organization: National Radio Astronomy Observatory
Date: Sat, 15 Aug 1992 18:22:29 GMT


You still need to use the .declare section in the report writer code, which
allows you to run the report directly.  To use a form as a front end you simply
create a frame from either vision or ABF, specify a report frame, and supply a 
report parameters form name; this form will contain fields for all the 
parameters specified in the .declare section of the rw code

Cheers,

Paul N. Neal (TSR Calgary)
pneal@ingres.com


From:	PONY::"tjb@MATH.AMS.ORG" 15-AUG-1992 00:26:25.16
To:	info-ingres@MATH.AMS.ORG
CC:	
Subj:	 

I am using report writer and wish to know how to pass a parameter.

Specifically, I wish to create a form with a statement requesting the user to enter a specified value on which to sort.  Once this has been done I want to run a report which selects the information and produces a printout.

The problem I am having is in passing a parameter which is held in the internal field name within the form into the reportwriter.

I have been able to do it by bypassing the form and just using the .declare statement within reportwriter. However, this does not give me enough control, since I wish to force uppercase characters for example.

Any suggestions?		e-mail me direct on I.D.Cope@uk.ac.Bradford      .thanks.
Newsgroups: comp.databases.ingres
From: al@cvgis.prime.com (Al Parker)
Subject: Re: ESQL Bug
Organization: Computervision GIS (Toronto)
X-Newsreader: Tin 1.1 PL4
Date: Thu, 20 Aug 1992 16:35:43 GMT

kmchylla@vms.macc.wisc.edu writes:
: >kmchylla@vms.macc.wisc.edu writes:
: > 
: >|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.   
: > 
: 
: Thanks for your questions!
: 
: Kathy Chylla

Having minimal experience with INGRES I may be just guessing but this
sounds exactly like problems I've had with INFORMIX transaction
logging.

Q: Are all updates being done within the same transaction ?

If so, then you may be running out of transaction log records. Your
production environment may be configured with more transaction log
records. Can you commit the records at regular intervals ?

Hope this helps...
-- 
-----------------------------------------------------------------------------
Al Parker, P.Eng, Sr Software Engineer - Computervision GIS
al@cvgis.prime.com	(416)508-8020(x881)
These opinions are my own and not those of my company.
Newsgroups: comp.databases.ingres
From: sfc@tpghq.com (Steve Caswell)
Subject: Re: Number of slave processes?
Organization: Palmer & Associates, Inc.
Date: Wed, 12 Aug 1992 17:06:58 GMT

>From: Cristyn Emmett <Cristyn.Emmett@newcastle.ac.uk>
>Subject: Number of slave processes?
>
>Hello,
>I am DBA for an Ingres 6.3/01 installation on a Sun 4/470 (SunOS 4.1.1)
>We have the four Ingres components /ingresdb, /ingresvar, /ingreslog and
>/licence/ingres each on a separate disk.
>We have been experiencing deadlock problems and I have experimented
>with decreased fillfactors in the (btree) tables which are most heavily
>used, also with adding secondary indexes to these tables.
>However, the problems continue.
>
>We are still only running two slave processes and I am wondering if it
>would be advantageous to increase this number to 4, or maybe more.
>Could anyone advise me of a suitable number, and perhaps of some check I
>could make 'before and after' to see what improvement, if any, has been 
>gained. 
>
>Thank you,
>
>Cristy
>
>Also known as:       
>cristyn.emmett@newcastle.ac.uk
>******************************

The number of slave processes you have should not affect whether or not you
are getting deadlock.  Deadlock occurs as the result of lock contention, whereas
the slaves are there only to perform disk i/o on behalf of the server.

Increasing the number of secondary indices on a table will not necessarily
eliminate deadlock either.  In fact, adding secondaries could compound the
problem.

Deadlock can occur for a number of reasons.  If possible, you should try to
determine what is causing the deadlock.  Heavy concurrency in btree tables can
be one cause of deadlock because INGRES needs to lock the index pages.  Other
causes include application design problems, too low a value for MAXLOCKS
(which causes lock level escalation which can cause deadlock), too low a value
for maximum locks per transaction (same effect as MAXLOCKS).

You should be able to use IPM and the ingres errlog.log file to determine
why deadlocks are occuring.  IPM contains an option which allows you to monitor
the locking system during periods of activity.  The errlog.log file will contain
entries for every lock wait, escalation, and deadlock.  The errlog.log is
located in the files subdirectory under the ingres root directory.



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."



-- 

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: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
Subject: Re: SQL 'like' command with case insensitivity?
Organization: 
Date: Fri, 14 Aug 1992 22:46:10 GMT

In article <1992Aug12.002043.1970@candle.uucp>, root@candle.uucp 
(Bruce Momjian) writes:
> I need to do an SQL statement where I need pattern matching that is
> case-insensitive.  In both SQL and 4GL, this statement is illegal:
> 
> 	select *
> 	from tablea
> 	where uppercase(col) like '%YES%';
> ...
> The only two workarounds I can think of are to add another column that
> always has 'col' as uppercase, or in 4GL to attach a block of code to
> the select and for every row, uppercase the field, and then compare with
> a select.

We've worried about this problem a lot because we want our users to be
able to look up people without having to type their names exactly right. 
As has been pointed out, one workaround is to define a view and rephrase
your query in terms of it:

	create view viewa as 
		select a.*,upcol=uppercase(col) from tablea a ;
	select * from viewa where upcol like '%YES%' ;

I didn't believe it at first, but it really works.  If your table is
large, then this will perform poorly even if there is a secondary index
on "col".

The choice we've made is, as you suggest, to have "derived" columns in
the table along with the original data.  For example, in our person
table we have  search_name and soundex columns in addition to the
last_name column.  The search_name is the last name converted to
uppercase, with all spaces and punctuation removed (actually everything
but letters).  The soundex is derived according to Knuth, The Art of
Computer Programming, Vol. 3, Sorting and Searching (Addison Wesley). 
We have secondary indexes on both of these things, so now our users can
rapidly look people up even if they can't remember whether the last name
is Damato, D'amato, d'Amato, or whatnot.

The disadvantage of this approach is that these inexact lookups by name
can _only_ be done with programming, because what the user types has to
be preprocessed by one of our special functions before it can be used in
the query itself.  So this approach doesn't work great with QBF, report
writer, etc.  But the added searching power is well worth it.

> In QUEL, it was easy, but that's another topic.

The price of standards (and following Big Blue).  8^)

> Bruce Momjian                      |  830 Blythe Avenue
> root%candle.uucp@bts.com           |  Drexel Hill, Pennsylvania 19026 
>                                    |  (215) 353-9879(w)  853-3000(h)

--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.

Newsgroups: comp.databases.ingres
From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
Subject: Re: setsid on sunOS 4.1.2
Organization: 
Date: Thu, 20 Aug 1992 22:13:18 GMT

In article <1992Aug20.165919.654@news.columbia.edu>,
howie@ivory.cc.columbia.edu (Howie Kaye) writes:
> We've had a problem with the ingres terminal monitor under sunOS
> 4.1.2 where it does not seem to be responding to terminal interrupts.
> I traced it to the setsid commands in all of the front end scripts
> for the various ingres programs (ie setsid -b ~ingres/tm -qquel).
> Things seems to work if i run tm by hand.
>
> I was wondering if there was actually a reason that those setsid's
> were there -- do they do anything useful, or can I just remove
> them?

What version of INGRES are you using?  The "setsid" doesn't appear in
the scripts for the "sql" and "quel" commands in release 6.4.

--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.

Newsgroups: comp.databases.ingres
From: marg@manila.cc.columbia.edu (Margarita Suarez)
Subject: Re: setsid on sunOS 4.1.2
Organization: Columbia University
Date: Fri, 21 Aug 1992 19:30:23 GMT

actually, the setsid's howie was talking about were put in by me on advice from
someone at ingres because without them, you can't properly run emacs with ingres
6.4 under sunos 4.1.2.  emacs worked with the setsids, but it turned out that
job control was screwed up.

has anyone else seen this problem or gotten ingres to work correctly?

marg
From: danny@itm.uucp (Danny Cox)
Newsgroups: comp.databases.ingres
Subject: A question and a Request
Date: 17 Aug 92 14:24:52 GMT
Reply-To: danny@itm.UUCP (Danny Cox)
Distribution: na
Organization: In Touch Ministries - Atlanta, GA

Greetings!

	First, the question.  We get many requests for the 'top N' rows from
a table.  How does one accomplish this in SQL?  Sorting is no problem,
but how does one request the first N rows?  Obviously one could do an
'endloop' to stop once N is reached in 4gl/ESQLC, but is there a better way?

	I saw today an article requesting regular expressions in SQL.  I 
quite agree.  I'd like a 'conditional expression' as C has, as well.  I could
certainly use one currently!

	Comments?

                                                   Danny
-- 
				Daniel S. Cox
				(gatech!itm!danny)
Newsgroups: comp.databases.ingres
From: drcoles@somnet.sandia.gov (Dwight R Coles)
Subject: Re:  Ingres 6.2 Versus Ingres 6.4 on SCO Unix 3.2.2 Versus SCO Unix 3.2.4
Organization: National Radio Astronomy Observatory
Date: Mon, 17 Aug 1992 21:29:52 GMT

> From: jaa@world.std.com (Jerry A Abramson)
> Subject: Ingres 6.2 Versus Ingres 6.4 on SCO Unix 3.2.2 Versus SCO Unix 3.2.4
> 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.
> 
> 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.
> 
Jerry, I believe you will find 6.4 on SCO much better than the older versions
released by SCO as a bundle with the OS.  We've moved up to the INGRES supported
version and are very happy with the additional quality and speed.

We moved ABF applications with merely a recompliation- your embedded stuff
should do the same.

Good Luck!   Dwight Coles - drcoles@sandia.gov
From: sm@sys.uea.ac.uk (Shaun McCullagh)
Newsgroups: comp.databases.ingres
Subject: Ingres 6.4 crashes Sun SPARCs    (Sun OS v 4.1.1B)
Date: 22 Aug 92 16:10:18 GMT
Organization: University of East Anglia
X-Xxdate: Sat, 22 Aug 92 17:12:04 GMT
X-Useragent: Nuntius v1.1.1d7


Hi,

There appears to be a bug in Ingres 6.4 that stops both Ingres & the Sun
Host it's running
on from recovering after a system crash. 

The problem occurs when iistartup is executed. Shortly after this event
Ingres crashes
the Sun. The only cure I've found so far is to delete ingres and restore
it from a dump tape.

I think the crash occurs when iistarup executes 'iinamu'.

Please mail any ideas/suggestions to me.

Thank you in advance for you help. 


Shaun McCullagh (RA)
School of Information Systems.,
University of East Anglia.,
Norwich
England NR4 7TJ

sm@uk.ac.uea.sys ( JANET )      	       	Tel +44 603 592692
sm@sys.uea.ac.uk ( Other Nets ) 	       	FAX +44 603 507720

*******************************************************************
What a terrible thing to have lost one's mind. Or not to have a mind at
all.  
How true that is. 
-- The Vice President of The United States of America : Dan Quayle 
*******************************************************************
From: waetzig@bcstec.ca.boeing.com (Todd Waetzig)
Newsgroups: comp.databases.ingres
Subject: Re: SQL 'like' command with case insensitivity?
Date: 12 Aug 92 21:28:50 GMT
Organization: Boeing Computer Services, Seattle

In article <1992Aug12.002043.1970@candle.uucp>, root@candle.uucp (Bruce Momjian) writes:
> I need to do an SQL statement where I need pattern matching that is
> case-insensitive.  In both SQL and 4GL, this statement is illegal:
> 
> 	select *
> 	from tablea
> 	where uppercase(col) like '%YES%';
> 

I attempted to respond to this question, but the postnews program did not 
include my summary in the text of the response. So here it is again

If you are going to be comparing to constants such as in your example, one
method would be as follows:

select *
from tablea
where col like '%\[Yy\]\[Ee\]\[Ss\]%' escape '\'

Give it a whirl...

-- 
Todd Waetzig		Programmer/Analyst 	Boeing Computer Services
T. Wa. :=>					 waetzig@bcstec.boeing.com
Newsgroups: comp.databases.ingres
From: betty@casbah.acns.nwu.edu (Betty Benson)
Subject: seeking reportwriter advice
Summary: need to select 1 of 2 queries 
Keywords: reportwriter, .query, .if
Organization: Northwestern University, Evanston Illinois.
Date: Mon, 17 Aug 1992 22:00:06 GMT
Expires: Tue, 15 Sep 1992 05:00:00 GMT

I am trying to convert some KnowledgeMan programs to Ingres reportwriter,
and I need to duplicate the situation where user can optionally restrict
the report to data within a given time-period.

In K-Man, user is prompted  "What starting date?  (yy/mm/dd or ALL)" .
If user says "ALL" then  variables ymd_a and ymd_z are to to 00/00/00
and 99/99/99 respectively.  (Yes, I know those particular pseudo-dates
won't work in Ingres, but that's not the problem.)

Otherwise user's response is input as ymd_a, and user is prompted for
ending date, which is input to ymd_z.  Then, of course, only data within
that  date-range goes into the report.  (If user said ALL, everything 
would be selected.)

SOooo...in reportwriter I can't have alternate queries under .IF
control, one with a where clause, and one without, to handle the ALL
response.  I can't put .LET statements in  (to define ymd_a and ymd_z)
between .DECLARE and .QUERY, apparently.

I'm new to reportwriter, so maybe there are simple solutions to this
problem -- all I can figure is to have 2 separate programs, one for 
ALL and one for user-selectable time-period.   Any help or advice 
would be much appreciated.
                             ==================================== 
                            /     betty@casbah.acns.nwu.edu    /
                           ====================================