HDTenEightyP/NetNews huggingface dataset:
From: ashmor@studsys.mscs.mu.edu (Robert Ashmore III)
Newsgroups: comp.databases.ingres
Subject: Help - Recursive Trees with Ingres
Date: 1 Sep 92 15:56:50 GMT
Article-I.D.: spool.3835
Reply-To: ashmor@studsys.mscs.mu.edu (Robert Ashmore III)
Organization: Marquette University - Department MSCS
Originator: ashmor@studsys.mscs.mu.edu

We are trying to do Bill of Material explosions with rules and
are also trying to do tree walking (down the tree) to do updates.
Anyone have a sample rule set to do this?

Thanks in advance.
-- 
Robert B. Ashmore III               |       "We are only immortal 
ashmor@studsys.mscs.mu.edu          |        for a limited time."   -  N.P. 
Newsgroups: comp.databases.ingres
From: "Warren Spencer (315) 349-0493" <EV2WS1%MISX01@KINGSTON.ARPC.ALCAN.CA>
Subject: Re: Varchar Columns with Binary Data
Organization: nrao
Date: Tue, 25 Aug 1992 18:07:00 GMT

>Hello, Netters!
>
>A coworker of mine had a question regarding the storing of binary data
>in a Varchar column when that binary data might have embedded null bytes
>(in INGRES, \000) using C under VMS.
>
>  ... more ...
>
>Running this program with a suitable table results in the value expected,
>in FORTRAN.  My coworker, using C, is not having the same luck.  It seems as
>though INGRES is only storing the first 7 bytes (up to the first \000 byte),
>even though he's following the manual about specifically setting the length
>of the string in his C code.
>
>Is there something funny that needs to be done?  Can anyone help?
>
>Bill Koster
>Computer Sciences Corporation
>301.497.2712
>KOSTER@CDHF1.GSFC.NASA.GOV

Hi Bill,

I have successfully performed this trick under Ingres 6.3/03 Vax/Vms 03, using 
embedded C.  I followed the examples/instructions in the documentation.  Some 
areas you might suspect are:

	- The table is not actually declared with a varchar column.
	- The program uses the name of the varchar structure member, instead of
	  the name of the varchar structure itself.
	- The varchar structure is improperly declared, perhaps the
	  keywork VARCHAR is missing.
	- The field length member of the varchar structure contains an
	  incorrect value.

Hope this helps,

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

Newsgroups: comp.databases.ingres
From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
Subject: <None>
Organization: 
Date: Tue, 1 Sep 1992 21:12:58 GMT

In article <1992Aug31.180720.7712@desktalk.desktalk.com>, eric@desktalk.com 
(Eric Lieber) writes:
> I want to insert a datetime value into a table. The format I have to use is:
> 	"yyyy-mm-dd hh24:mi:ss"
> where hh24 is the 24 clock , (13:00 = 1:00 pm)
> 
> After reading the manual, I assume that the  II_DATE_FORMAT varable must
>  be to set to  'SWEDEN/FINLAND'.
> 
>  The question is will Ingres  accept the following:
>  insert into test_table (date_col)
>            values (	"1992-12-31 13:45:59");

Yes, it works.  You can use either of these (for VMS):

		$ define ii_date_format "SWEDEN"
		$ define ii_date_format "FINLAND"

For Unix csh:

		% setenv II_DATE_FORMAT SWEDEN
		% setenv II_DATE_FORMAT FINLAND

Note that you must use _single_ quotes (') in your insert statement. 
Double quotes (") are not allowed.

--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: kerry@Ingres.COM (Kerry Kurasaki)
Newsgroups: comp.databases.ingres
Subject: Re: Sun Ingres 6.4/01 BUG notice
Date: 25 Aug 92 17:44:11 GMT
Reply-To: kerry@Ingres.COM (Kerry Kurasaki)
Organization: Ask Computer Systems Inc., Ingres Division, Alameda CA 94501

In article <1992Aug25.095936.487@csc.canterbury.ac.nz> pete@cosc.canterbury.ac.nz (Pete Glassenbury) writes:
[Finds 'A' bug in INGRES]
>
>ARGHHHH -- I wish the could notify people (there can't be that many
>sites in each country with "support") when there are these serious bugs
>with a new upgrade. To hide it until someone asks about it is very
>annoying. 
>(This is the reason for this post so other people may have some
>foreknowledge)
>

To put on my 'Official Ingres Employee Hat on':

It would be nice if we could do this, but unfortunately, in a commercial,
competitive environment like we have in this country, bug listings have
been used as product bashing by nameless competitors.

Product defect (bug) information is available under support services.
Dial-up (modem) access to consult our expert database is available 24
hours a day.  You can email me for futher information.  I am planning
to put support options in the FAQ if I ever get it finished.

Kerry Kurasaki
kerry@ingres.com
Newsgroups: comp.databases.ingres
From: pneal@ingres.com (Calgary (Kal-gree), (403) 262-8119)
Subject: re: Case sensitivity in LIKE clause in SELECT statements
Organization: nrao
Date: Tue, 25 Aug 1992 18:00:30 GMT

jarnot@kin.lap.upenn.edu (Kevin J. Jarnot) wrote:

> Is it possible to turn off case sensitivity in a SELECT statement when
> using the LIKE clause?  I want to search for a string using a template,
> something like "wom%".  This template should be able to match "Wombat",
> "wombat", "WoMbAtS", etc...I currently convert the template to 
> "\[Ww\]\[Oo\]\[Mm\]%", but the SELECT statement takes forever...
> 
> Any ideas?
> 
> 
> Kevin
> 


This is a solution I provided for a client, who wanted to retreive records
sorted without regard to case, with range access on the same column.  One 
solution required use of uppercase() in a where clause, the other required the
creation of a secondary index using the uppercase() function.

What I suggested was to mimic a secondary index ...


create table x (col1 varchar(20), ...)
create table index_x (upper_col1 varchar(20), tid_pointer integer)
create view  table_x as select col1, upper_col1, ... 
  from x, index_x y
 where x.tid = y.tid_pointer;

All selections were performed against table_x ...

Select col1, ... from table_x where upper_col1 like ...

The tables were kept in sync via rules ...

create rule xxx on insert/update/delete into/of/from x
  execute procedure sync_index(col1=col1, tid_pointer=tid);

create procedure sync_index(col1=varchar(20), tid_pointer=integer) as
begin
    insert into index_x values (uppercase(:col1), :tid_pointer)
 or 
    update/delete ... index_x where tid_pointer = :tid_pointer

    if iirowcount <> 1 then
        error routine ...
    endif
end


... and the maintenance script which modified x also included sql for index_x ..

modify index_x to truncated;
insert into index_x select uppercase(col1), tid from x;
modify index_x to ...;

This worked well for the client in question, who used a btree structure on 
index_x(col1), and hashed the tid_pointer column.  Of course the use of the tid
column, while useful, is not necessarily recommended (this same functionality 
could be utilized with surrogate keys).  Volume of data and methods of access
required will determine what structures are best suited to a given application.
You would want to check QEP's against a populated database.

Cheers,

Paul N. Neal (TSR Calgary)
pneal@ingres.com
Newsgroups: comp.databases.ingres
From: sriram@tcs.com (Sriram Srinivasah)
Subject: FAQ ?
Organization: Teknekron Communications, Inc
Date: Sun, 30 Aug 1992 17:50:41 GMT

Is there an FAQ for this group ?
Also, can someone tell me about newsletters/magazines etc. devoted to Ingres?

Sriram
(sriram@tcs.com)
Newsgroups: comp.databases.ingres
From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
Subject: Re: Funny "union" behavior
Organization: 
Date: Mon, 31 Aug 1992 21:25:31 GMT

In article <ricky.715238450@citr.uq.oz.au>, ricky@citr.uq.oz.au 
(Ricky Leung) writes:
> I have been having some funny behavior from using Ingres' Union (6.4/01).  
> I have two tables: test1 and test2.  "c1" is the key in both tables.
> ...
> I have two queries (Q1 and Q2) that I would like to union their
> results.  Running the queries individually [results in one row each].
> ...
> Running them as "Q1 union Q2" gives me an extra row (ROW 1)????
> ...
> Running them as "Q2 union Q1" gives me two extra rows (ROW 3 and 4)????
> ...
> From my understanding of the union operator, the union should give me 
> the "set union" of the results of the two individual queries.  Am I 
> doing something wrong, or is it an Ingres feature or bug?

It sure looks like a bug to me.  I can't see what you're doing wrong. 
What does Ingres Tech Support have to say?

Sometimes you might get _fewer_ rows than you expect out of a UNION,
because by default INGRES eliminates duplicates rows from a UNION
SELECT.  If you want to retain the duplicate rows, then you must use
"UNION ALL", and use it in all UNION's in the grand SELECT.  Read the
conceptual description of how SELECT's are executed in the SQL Reference
Manual, p. 7-232 (release 6.4, Dec. 1991; Chapter 7, SQL Statements;
section called "Select (interactive)").

A wild guess is that this is a problem having to do with query
flattening.  By default, INGRES uses query flattening to enhance the
performance of many common subselect queries.  In essence, the server
does things like converting this:

	select t1.* from t1 where t1.id in ( select t2.id from t2 ) ;

into this:

	select t1.* from t1 , t2 where t1.id = t2.id ;

This is fine, except that it doesn't conform to ANSI SQL semantics.  If
you use the "=" predicate instead of "in", then ANSI SQL demands that
the query return an error if the subselect gives more than one row. 
With query flattening, the query works just fine even if there's more
than one row.

I know there's a trace point to turn _on_ query flattening, because we
needed it in an earlier version, before Ingres decided to make
flattening the default behavior.  But I don't know how to turn it off.  

I suggest spending a pleasant half hour with Tech Support.

--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: Li.1@nd.edu (guoben li)
Newsgroups: comp.databases.ingres
Subject: Ingres Tools
Date: 31 Aug 92 17:01:31 GMT
Distribution: usa
Organization: University of Notre Dame, Notre Dame


We are looking for some Ingres tools and got the brief information about
		I/DBA of Common Sense Tools and
		INGdba of Aegis Products, Inc.

If anyone has experiences on either of them please give your comments
(or your phone number so that I could call you).

Thanks in advance.


Guoben Li
Networking Services
University of Notre Dame
From: jj23+@andrew.cmu.edu (John Hawfeng Jeng)
Newsgroups: comp.databases.ingres
Subject: query on date
Date: 28 Aug 92 18:09:25 GMT
Article-I.D.: andrew.IebhlJS00io7AIuUlc
Organization: Masters student, Information Networking Institute, Carnegie Mellon, Pittsburgh, PA

I would like to make some query base on date using BETWEEN.  Can anyone
verify the following query for me since I could not find anything
similar in the reference manual?

	select *
	from transaction
	where date_time_of_transaction between :start_date and :end_date
	and account_number = :in_account_number;

Thanks in advance,
John Jeng
From: cbh@opus.mlb.semi.harris.com (Cherie Slasor)
Newsgroups: comp.databases.ingres
Subject: Re: need TERMCAP entry for shelltool or cmdtool on SUNOS/4.1.2
Date: 27 Aug 92 20:27:37 GMT
Organization: Harris Semiconductor, Melbourne FL

In article <1992Aug27.150306.18494@emr1.emr.ca> guest@cg.emr.ca writes:
>The termcap entries provided by INGRES for the SUNOS/openwindows are not satisfactory.
>Has anyone written a better termap for the SUN (shelltool or cmdtool windows)? If so,
>could you send me a copy at mcneil@seismo.emr.ca.  Also, is there a FAQ for this group?
>If so, is it archived at a FTP site anywhere?

I'd like to have this, too, if somebody's mailing one.

-- 
====================================================================
Cherie Slasor			     |	Harris Semiconductor
Phone:    (407) 724-7607	     |	P.O. Box 883, MS #62B-022
          cbh@mlb.semi.harris.com    |  Melbourne, FL   32902-0883
From: gnb@duke.bby.com.au (Gregory N. Bond)
Newsgroups: comp.databases.ingres
Subject: Bug in termcap cm=/cs= handling.
Date: 2 Sep 92 04:27:31 GMT
Organization: Burdett, Buckeridge & Young, Melbourne, Australia

I've finally tracked down the bug in Ingres termcap handling that has
plagued us since I don't know when, maybe even 5.0, and still exists
in 6.4/01 su4.2/02 on the Sun 4.  It is to do with using cs= (change
scrolling regions) in termcap entries.

The cm= (cursor motion) entry has a flag "%i" that says the terminal
in question counts lines (and columns) from 1, not 0.  So if you are
using an xterm or vt100 or whatever, you need the %i.  The
documentation for cs says its just like cm except that it talks in
lines, not lines+columns.  This would lead one to expect that if cm
needed %i, so would cs, and indeed all in unix system termcaps I have
used (and that goes way back to 4.2 on a vax) this is true.

Not so in Ingres.  The cs termcap entry assumes lines are numbered
starting with 1, so the %i is NOT correct.  This leaves a fundamental
and undocumented inconsistency between cm and cs.  The worst part of
this is that if your terminal does indeed count lines from 0, you can
never use cs because there is no "anti-%i" flag!

Close examination of the "unsupported" xterm termcap distributed with
Ingres shows this.  However, we developed our own termcaps based on
the existing system termcaps rather than starting with an Ingres entry
and adding stuff, so we carried over the (correct, IMHO, but wrong for
Ingres) usage for cs.

(This was most visible under QBF, when using simplefield mode on a
table that had more than 1 screenfull of fields.  Scrolling off the
bottom of the displayed data or using page down would confuse the
screen and leave it in a funny scrolling state once QBF was exited.)

Greg.
--
Gregory Bond <gnb@bby.com.au> Burdett Buckeridge & Young Ltd Melbourne Australia
``USL has never sold long distance.  You're going after the wrong men in black 
  hats.  (Or, in the case of Plan 9, black space suits)'' - Tom Limoncelli
From: ageorge@ra.nrl.navy.mil
Newsgroups: comp.databases.ingres
Subject: infinite loop of INGRES/NET connections
Date: 27 Aug 92 20:52:29 GMT
Reply-To: ageorge
Organization: Naval Research Laboratory, Washington DC
News-Software: VAX/VMS VNEWS 1.3-4


	Hello everyone,

	I use INGRES V6.3 on a Silicon Graphics Personal Iris 4D/35 running
IRIX V3.3.2.

	In "INGRES/NET User's and Administrator's Guide for UNIX and
VMS Operating Systems" Release 6.2 and 6.3 November 1989, pg 3-36, the author's
advise that, with INGRES/NET installed, one ought not set the local v_node to
be the same as the remote v_node. In this case, the remote v_node actually
points to the local node. They go on to say that if the local v_node
were defined incorrectly, one would have an infinite loop of INGRES/NET
connections.

	As I see it, the procedure is something like this:

	LVNODE:	if (lvnode_correct) connect;
		else
			if (rvnode_correct)
			{
				connect;
				if (!lvnode_correct) goto LVNODE;
			}

	My questions are:

	(1)	How does one define a local v_node incorrectly and
		not have INGRES detect it, stop the connection, and print
		a message?

	(2)	Is my procedure correct? If it isn't, can one of you explain
		the process of getting an infinite loop of
		INGRES/NET connections(as if I'd wish it on someone)?

	I would try this out on my own, but I'm loathe to possibly crashing
a workstation. Perhaps an INGRES person or anyone with the benefit
of experience can help out.

	Thank you in advance,
	Arthur George, NRL
	ageorge@BDCI143.nrl.navy.mil
Newsgroups: comp.databases.ingres
From: lehman@bobhome.enet.dec.com (Bob Lehman)
Subject: Re: Case sensitivity in LIKE clause in SELECT statements
Reply-To: lehman@bobhome.enet.dec.com (Bob Lehman)
Organization: Total Software Distributions Fremont, CA
Date: Tue, 25 Aug 92 20:20:58 GMT



Another approach you might consider is User Defined Data types. There is
an example of ZCHAR which is a data type that I think supports matching 
case sensitive data.  Look in 

II_SYSTEM/ingres/demo/udats

for the examples.

I not sure but I think this is a 6.3 on up feature, and it is not very well
documented.

If any one from ingres is monitoring this, more information about this feature
would be appreciated.

--Bob
Newsgroups: comp.databases.ingres
From: cole@leda.sun.csd.unb.ca (Michael Cole CSD)
Subject: Terminal type names 
Keywords: SPARCstation IPX, IBM3151
Organization: University of New Brunswick
Date: Tue, 25 Aug 1992 22:04:49 GMT

	This will be my first posting of probably hundreds in this newsgroup.  I've just been signed onto to a group project using INGRES and I've already hit my first road block. I use two terminals mainly: the SPARCstation IPX and an IBM3151.  Would anyone know the terminal names for these so I can set my environment.  Thanks.

Michael Cole, Univ of New Brunswick
From: U33720@uicvm.uic.edu (Fardad)
Newsgroups: comp.databases.ingres
Subject: ESQL does not recog. CDD!
Date: 3 Sep 92 04:48:10 GMT
Article-I.D.: uicvm.92246.234810U33720
Organization: University of Illinois at Chicago

hi;
      I am writting an embedded application using Ingres SQL and
 Vax Basic under VMS. I was surprised to see that THE INTELIGENT! database's
preprocessor does not recognizes VMS's CDD:
     exec sql begin declare section
       %include %cdd "cdd record type name"
     exec sql end declare section

when you run this thru preprocessor gives SYNTAX ERROR.
Anyways to get around it?

 DO you now of a VMS system call that would create a structur based on
   a CDD definition and a specified VAX language?
 A function doing the above MUST exist; all VAX compilers do use it.

please enlighten this frustrated user of an INTELIGENT rdbms!

fardad
From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
Newsgroups: comp.databases.ingres
Subject: Re: Database Procedure
Date: 3 Sep 92 21:26:38 GMT

In article <9209021504.AA09237@csd.hku.hk>, chou@csd.hku.hk (Chou Sui Lin) 
writes:
> We hit a certain limit while trying to incorporate some pretty hugh
> database procedures to Ingres 6.4. Just wondering what those limits are
> and how to reset them. In addition, what are the effects to the whole
> server in general?

What limit did you hit?

When you create a database procedure, the server needs space in QSF
(query storage facility) to store the original text and the "compiled"
version of the procedure and its queries; in PSF (parser facility)
during the parse phase; and OPF (optimizer facility) for the
optimization phase.  Remember that all queries in a database procedure
get optimized once at creation time, and then the already-compiled query
plan is stored in QSF and fetched whenever a front end wants to execute
the procedure.

You may need to change some or all of these parameters on the server (in
the iirundbms file or its options file or whatever):

	opf=memory=n
	opf=active=n
	psf=memory=n
	qsf=pool_size=n

If you increase any of the memory parameters, then the overall effect on
the server will be to increase its memory requirements.  It will require
more physical memory or swap space (in Unix), or a larger working set
(in VMS).

--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: heja@ise.fhg.de (Herbert Jaegle)
Subject: Re: Sun Ingres 6.4/01 BUG notice
Organization: FhG-ISE - Institute for Solar Energy Systems
Date: Wed, 26 Aug 92 18:00:10 GMT

kerry@Ingres.COM (Kerry Kurasaki) writes:

>In article <1992Aug25.095936.487@csc.canterbury.ac.nz> pete@cosc.canterbury.ac.nz (Pete Glassenbury) writes:
>[Finds 'A' bug in INGRES]
>>
>>ARGHHHH -- I wish the could notify people (there can't be that many
>>sites in each country with "support") when there are these serious bugs
>>with a new upgrade. To hide it until someone asks about it is very
>>annoying. 
>>(This is the reason for this post so other people may have some
>>foreknowledge)
>>

>To put on my 'Official Ingres Employee Hat on':

>It would be nice if we could do this, but unfortunately, in a commercial,
>competitive environment like we have in this country, bug listings have
>been used as product bashing by nameless competitors.

>Product defect (bug) information is available under support services.
>Dial-up (modem) access to consult our expert database is available 24
>hours a day.  You can email me for futher information.  I am planning
>to put support options in the FAQ if I ever get it finished.

>Kerry Kurasaki
>kerry@ingres.com

It's nice to have 24 hour defect information, but i would prefer to get
24 hour availability of the database. We are running
Ingres 6.4/01 (hp3.us5/00) under HPUX 8.0 and reported a bug
in the database engine with datatype money. This bug reported 29. April 92
has not been fixed till now (4 months) and resumes in time between
failure of 4 hours for our applications.

Herbert
--
-------------------------------------------------------------------
Herbert Jaegle        Fraunhofer Institute for Solar Energy Systems
DL7GAP               Oltmannsstr. 22, D 7800 Freiburg, West Germany
heja@ise.fhg.de   phone: +49 (761) 4014 126 fax: +49 (761) 4014 200
-------------------------------------------------------------------
Newsgroups: comp.databases.ingres,comp.databases.sybase
From: sophia@omega.mel.dms.CSIRO.AU (Sophia Liow)
Subject: Re: information request
Originator: sophia@omega.mel.dms.CSIRO.AU
Keywords: ingres, sybase
Organization: CSIRO, Div. of Mathematics & Statistics, Melbourne, Vic., AUSTRALIA
Date: Mon, 31 Aug 1992 08:43:19 GMT

In article <Bttnp6.MDn@syd.dms.CSIRO.AU>, sophia@mel.dms.CSIRO.AU (Sophia Liow) writes:
|> We are in the process of trying to set up some databases. 
|> Currently we have 3 in mind
|> 
|> - a database of customer information 
|> - a database for bug reporting of software that we develop
|> - a database for keeping track of user problems/requests within our
|>   division and our response.
|> 

I forgot to give an indication of the size of databases we could be
handling, so here is some rough estimates to help you to help me:

- a database of customer information 

currently we have about 700 customers, some with cross information, and
expected growth of this will be about 5 a month.

- a database for bug reporting of software that we develop

expect about a 100 bugs reported a month, with some human intervention on
allocating severity status, status and possibly a couple of other fields.

- a database for keeping track of user problems/requests within our
  division and our response.

we estimate that we get 20-30 requests a week, this number will fluctuate,
so maybe overall 2000 a year.

e-mail response will be much appreciated.
Thank you once again

(:------------------------*   *----Sophia --------------------------Liow----:)
|    +==^      ,           \ /  CSIRO, Div. of Mathematics & Statistics      |
|    !__  _ !_.!_  "  _     I   Private Bag 10, Clayton, VIC 3168, Australia |
|       !{_}!_}! ! % {_&.   I   email: sophia@mel.dms.CSIRO.AU               |
|    `=='   !              / \  Tel: +61 3 542 2267   Fax: +61 3 542 2474    |
(:------------------------*   *---------------------------------------------:)



Newsgroups: comp.databases.ingres