HDTenEightyP/NetNews huggingface dataset:
From: ricky@citr.uq.oz.au (Ricky Leung)
Subject: Funny "union" behavior
Summary: Funny "union" behavior observed in Ingres 6.4/01
Keywords: ingres, union, features, bugs
Organization: Prentice Centre, University of Queensland
Date: Mon, 31 Aug 1992 05:20:50 GMT

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.
Using "isql":

SQL> select * from test1

SQL> c1      c2
SQL> ------------------------
SQL> a       02-feb-1992
SQL> b       02-feb-1992
SQL> d       10-oct-1992


SQL> select * from test2

SQL> c1      c2
SQL> ------------------------
SQL> a       01-jan-1992
SQL> b       07-jul-1992
SQL> c       03-may-1992

I have two queries (Q1 and Q2) that I would like to union their
results.  Running the queries individually:

SQL> select c1, c2, 'ok' from test1 t1
SQL> where t1.c2 > (select max(c2) from test2
SQL>                where t1.c1 = c1)

SQL> c1      c2              col3
SQL> -----------------------------
SQL> a       02-feb-1992     ok


SQL> select c1, c2, 'not' from test1 t1
SQL> where t1.c2 <= (select max(c2) from test2
SQL>                where t1.c1 = c1)

SQL> c1      c2              col3
SQL> -----------------------------
SQL> b       02-feb-1992     not

Running them as "Q1 union Q2" gives me an extra row (ROW 1)????

SQL> select c1, c2, 'ok' from test1 t1
SQL> where t1.c2 > (select max(c2) from test2
SQL>                where t1.c1 = c1)
SQL> UNION
SQL> select c1, c2, 'not' from test1 t1
SQL> where t1.c2 <= (select max(c2) from test2
SQL>                where t1.c1 = c1)

SQL> c1 c2              col3
SQL> -----------------------------
SQL> a  02-feb-1992     not
SQL> a  02-feb-1992     ok
SQL> b  02-feb-1992     not

Running them as "Q2 union Q1" gives me two extra rows (ROW 3 and 4)????

SQL> select c1, c2, 'not' from test1 t1
SQL> where t1.c2 <= (select max(c2) from test2
SQL>                where t1.c1 = c1)
SQL> UNION
SQL> select c1, c2, 'ok' from test1 t1
SQL> where t1.c2 > (select max(c2) from test2
SQL>                where t1.c1 = c1)

SQL> c1      c2              col3
SQL> -----------------------------
SQL> a       02-feb-1992     ok
SQL> b       02-feb-1992     not
SQL> b       02-feb-1992     ok
SQL> d       10-oct-1992     ok

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?


--
Ricky Leung				    
Centre for Information Technology Research   Phone: +61 7 365-4321
The University of Queensland		     Fax:   +61 7 365-4399
Queensland  4072, Australia		     Email: ricky@citr.uq.oz.au
From: horn@schaefer.math.wisc.edu (Jeffrey Horn)
Newsgroups: comp.databases.ingres
Subject: Preprocessor for ABF code
Date: 26 Aug 92 21:47:46 GMT
Organization: Univ. of Wisconsin Dept. of Mathematics

Does anyone know if there is an environment variable that can be set that
will allow one to preprocess ABF code?  I know there is a variable that
allows postprocessing of vision code, but I would like to accomplish the
same thing with straight ABF.

Thanks, 

Jeffrey Horn
From: daryl@piano.adept.ih.att.com (55000-Daryl Monge(ih1439)392)
Newsgroups: comp.databases.ingres
Subject: Re: Sun Ingres 6.4/01 BUG notice
Date: 27 Aug 92 23:00:21 GMT
Organization: 5ESS(TM)-US Release Management
In-reply-to: pete@cosc.canterbury.ac.nz's message of 24 Aug 92 21:59:35 GMT

In article <1992Aug25.095936.487@csc.canterbury.ac.nz> pete@cosc.canterbury.ac.nz (Pete Glassenbury) writes:

	 ::[2136   , 0051E040]:
	   Thu Aug 20 11:08:20 1992 E_OP0392_HISTINCREASING  consistency check 
       - an histogram was detected which was not monotonically increasing


Yup, it is bug #41843.  It is in front of me right now in the corrections list
for release 6.4/02
From: croft@csusac.csus.edu (Steve Croft)
Newsgroups: comp.databases.ingres
Subject: Re: Blobs in Ingres 6.5
Date: 1 Sep 92 17:57:57 GMT
Organization: California State University, Sacramento

I wrote:
>INGRES engineers at the INGRES World Servers discussion said that
>BLOBs will be seperate from normal data pages and there will still
>be a 2000 byte limit.

I wanna clarify that the 2000-byte limit will still exist on normal
data pages, not BLOBs.

steve
From: jude@jeeves.ucsd.edu (Jude Poole)
Newsgroups: comp.databases.ingres
Subject: BTREE errors
Date: 26 Aug 92 20:09:33 GMT
Article-I.D.: sdcc12.37290

We are running ingres 6.4/01 (su4.u42/01) on a Solbourne (Sparc)
system and have encountered a serious corruption problem.  There are
no errors list in errlog.log, but two of our tables now show many problems
with verifydb.  We had a similar problem under 6.3 which as explained
as a bug in btree tables where transactions were improperly backed out
but supposedly this was fixed in 6.4.  Does anyone have any idea of
what might currupt tables this way under 6.4?  

Jude Poole
UCSD
jpoole@ucsd.edu
Newsgroups: comp.databases.ingres
From: sriram@tcs.com (Sriram Srinivasah)
Subject: C++ interface to Ingres
Organization: Teknekron Communications, Inc
Date: Thu, 3 Sep 1992 14:51:38 GMT

Does anyone have a neat encapsulation of Ingres dynamic SQL in C++ or C, 
preferably C++ ? 

Sriram
(sriram@tcs.com)
Newsgroups: comp.databases.ingres
From: Gavin Trigg <gavin@asis.unimelb.EDU.AU>
Subject: Re: ingres on a PC
Organization: National Radio Astronomy Observatory
Date: Wed, 2 Sep 1992 21:31:26 GMT

> 
> 
> 	Hi all -
> 	i have a question regarding accesssing ingres from a networked P.C
> 	i've developed an abf application on a sun sparcstation that is 
> 	accessed from a shelltool. i now want to see what the screen looks 
> 	like *full-screen* rather than squinting at the shelltool window.
> 	i can log on to ingres from a pc but the keyboard doesn't have the 
> 	*L* and *R* function keys - i think it's a vt 100f.
> 	is there a way i can use ingres on a pc by some how mapping to 
> 	different keys ? the *f* keys don't seem to work either
> 		 thank you in advance for any suggestions,
> 
> 			jake:-) 
> 
You'll need to check that your PC emulator mimics a vt100 and look in the
documentation for its equivalent of the vt100 keypad keys.  When you work all
this out set TERM_INGRES to vt100f.  Otherwise set TERM_INGRES to vt100 and
operate without function keys and use ESC to get to the menu line and enter the
leading unique characters to select the menu choice.

-- 
Gavin Trigg	Internet: gavin@asis.unimelb.EDU.AU
		Telephone: +61 3 344 6003 	Fax +61 3 347 4803
Data Base Administrator, Information Technology Services (ASIS),
The University of Melbourne, Parkville, Australia.  3052.
From: amueller@hpcc01.corp.hp.com (Amy Mueller)
Date: Wed, 26 Aug 1992 00:06:45 GMT
Subject: Replicating Databases
Organization: the HP Corporate notes server
Newsgroups: comp.databases.ingres

We are investigating different ways to perform database replication.  The
latest inquire_ingres newsletter had a good article describing the different
techniques.

Has anyone out there already done this?  If so, I'd like to learn of the
particular technique you used, and what works well and not so well.  Please
email me and I'll summarize the responses in about a month.

Amy Mueller
Hewlett-Packard Co.
From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
Newsgroups: comp.databases.ingres
Subject: Re: sysmod error
Date: 1 Sep 92 20:40:17 GMT

In article <1992Sep1.044648.10126@jyu.fi>, jukka@jyu.fi (Jukka Hartikainen) 
writes about a problem with sysmod:
>>>
>>>Sysmoding database 'intro' . . .
>>> 
>>>  Modifying 'iiattribute' . . . 
>>>E_US1200 Table name is not valid.
>>>    (Mon Aug 31 10:37:49 1992)
>>>
>>>Sysmod of database 'intro' abnormally terminated. 

Ken Weiner of Ingres suggests looking for a table called "iirtemp" and
dropping it.  It gets created and then dropped by sysmod, but it may get
left lying around if sysmod is interrupted.  Jukka responds:

>  Yes,  iirtemp really exists. I can see it with help table but when I'll 
>  drop it I get error:
> 
>  1>drop table iirtemp
> E_RD0060 Cannot access table information due to a non recoverable DMT_SHOW
>     error
>     (Tue Sep  1 07:34:49 1992)
> 
> E_DM0075 Invalid attribute record read while attempting to open a table.
>     (Tue Sep  1 07:34:49 1992)
> 
> E_SC00206 An internal error prevents further processing of this query.   
>     Please contact...
> 
> So...?

I think I've seen this problem before.  Look in the INGRES error log
(ii_config:errlog.log), and verify that the server reports the DMT_SHOW
error because the file does not exist.  The problem is that the table is
still there in the system catalogs, but there's no corresponding OS file
in the data directory for the database.  

I've solved this in the past as follows.  Select from the iifile_info
system catalog to learn what file name INGRES is looking for, for this
table.  You can do this with SQL, ISQL, or QBF.  If you have an extended
database then remember that there can be multiple files for one table.

Get privileges or ask your system manager to do the following.  Go to
the data directory for the database and create an _empty_ file with the
correct name.  If the table has secondary indexes and the files for them
are missing too, then you'll have to create empty files for them as
well.

Now you should be able to drop the table using the method from before.  

This is, of course, unsupported because you're messing around in the
data directory for the database, which is supposed to remain under the
control of the dbms server at all times, and never messed with directly
by users.  However, there's little danger if all you want to do is
_drop_ a table, and you take care in specifying the file names
correctly so you don't write over a legitimate table.

Good luck.

--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
Subject: SVR4.2
From: johnd@unisys.co.nz (John Dobson)
Date: Thu, 3 Sep 1992 04:12:42 GMT
Organization: Unisys New Zealand
X-Newsreader: Tin 1.1 PL4

Anybody know if Ingres is certified on an Intel 486 PC platform running SVR4.2,
in particular I'm interested in the 4GL product to run client/server to a
Sun / Sequent backend.

John Dobson.
Newsgroups: comp.databases.ingres
From: sfc@tpghq.com (Steve Caswell)
Subject: Re: using "ping" and "pong" tables
Organization: Palmer & Associates, Inc.
Date: Wed, 2 Sep 1992 17:34:22 GMT


>I have a number of large "production" tables that are being hit on
>interactively 'round the clock primarily for reads plus a bunch of 
>"overnight" update jobs lock these tables exclusive for extended
>periods.  I was thinking about have two versions of the same table,
>and ping-ponging back and forth between them by simply having all my
>programs use a variable for the "current" table which itself would
>be in a table somewhere.  This seems like it is probably a pretty
>common practice and I figured I see if any of you have any pointers....
>Thanks.
>/a

One problem you will have if you are using Embedded/SQL is that you can't simply
"use a variable for the current table" in standard SQL.  You would have to 
convert all your queries to Dynamic SQL, which may or may not be difficult
depending on what you are doing.  Most non-select statements can be performed
rather easily in Dynamic SQL without much work, as can singleton selects.
Multiple row selects require more work, and setting up the code for this is
not trivial.

Also, do not forget about the performance considerations of Dynamic SQL. Dynamic
SQL is typically a worse performer than straight SQL for a couple of reasons:

   1.  You cannot use the repeated operator with a dynamic statement, so you
       lose the benefit of repeated queries.

   2.  The overhead of performing dynamic selects can require more communication
       with the server (if you are using dynamic SQL to build an SQLDA, which is
       a data structure that describes the result columns of a select
       statement).

I think the above warning may also hold true for ABF/SQL, though I'm not
positive.  ABF prior to 6.4 does not support any flavor of Dynamic/SQL, and 6.4
supports only a subset of Dynamic.



-- 

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: jukka@jyu.fi (Jukka Hartikainen)
Subject: sysmod-error solved
Organization: University of Jyvaskyla, Finland
Date: Tue, 1 Sep 1992 13:41:35 GMT

The problem was really temporary table iirtemp. I couldn't drop that with
sql but verifydb -Odrop_table -flag works, iirtemp is gone and sysmod OK.
Thanks for information of iirtemp.

---Jukka
-- 
Jukka Hartikainen                       *
Jyv{skyl{n yliopisto / laskentakeskus   *
Seminaarinkatu 15                       *
SF - 40100 JKL, FINLAND                 *
Newsgroups: comp.databases.ingres
From: eric@brolga.cc.uq.oz.au (Eric Halil)
Subject: Setting up error handling routines (ABF 6.4)
Organization: Prentice Centre, University of Queensland
Date: Wed, 2 Sep 1992 09:58:32 GMT

I have a ABF application in which I what to trap all database error messages,
e.g. "DUPLICATE ROW ON INSERT DETECTED", and so on.

I had a quick look in the ABF manual and did the following:
----
int myhandler (errno)
int     *errno;
{
int     status = 0;

switch (*errno)
        {
        default: status = 0; /* suppresses message */
                break;
        }
return (status);
}

With a call to IIseterr(myhandler);

Unfortunately this also traps validation error messages from the forms.
I guess I just need to be more discerning in the switch stmt.  Can anyone
tell me the values to use to allow the forms validation messages and to stop
the database messages?

Thanks,
Eric.
--
Eric Halil                           |Internet/CSnet:         eric@cc.uq.oz.au
Prentice Centre                      |Bitnet:    eric%cc.uq.oz.au@uunet.uu.net
University of Queensland    4072     |UUCP:        uunet!munnari!cc.uq.oz!eric
AUSTRALIA --   Phone: +61 7 365 3610 |JANET:        eric%cc.uq.oz.au@uk.ac.ukc
Newsgroups: comp.databases.ingres
From: pdoxguru@med.unc.edu (Jeffrey J. Hunter)
Subject: Re: Sun Ingres 6.4/01 BUG notice
Organization: UNC School of Medicine
Date: Tue, 25 Aug 1992 21:03:10 GMT

In article <1992Aug25.174411.21797@pony.Ingres.COM> 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.
>

But it's YOUR responsibility to inform YOUR users of these potential 
problems with "upgrading" our databases.  WE pay YOU the big bucks for
"support", WE shouldn't have to hear about it on the net or for god sakes
dial into a bbs.   


-- 
!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=
It's worth it.  Because at the finish line, tenths of a second are a 
lifetime apart.      - Mike Vespoli
ARPA: pdoxguru@med.unc.edu; MABELL: (919) 966-1325
Newsgroups: comp.databases.ingres
From: jukka@jyu.fi (Jukka Hartikainen)
Subject: Re: sysmod error
Reply-To: jukka@jyu.fi
Organization: University of Jyvskyl, Finland
Date: Tue, 1 Sep 1992 04:46:48 GMT

In article 1383@pony.Ingres.COM, kenw@Ingres.COM (ken weiner) writes:
>In article <1992Aug31.090401.21554@jyu.fi> jukka@jyu.fi (Jukka Hartikainen) writes:
>>
>>I've seen lot of errors, but this never. Platform is Sun SS2, 4.1.2. and
>>Ingres is 6.2/03p (su4.u42/01). The database 'intro' seems to be OK, it
>>is in use, I can retrive data from it's iiattribute, but... Can somebody
>>tell me what's going on. Thanks.  ---Jukka.
>>
>>Sysmoding database 'intro' . . .
>> 
>>  Modifying 'iiattribute' . . . 
>>E_US1200 Table name is not valid.
>>    (Mon Aug 31 10:37:49 1992)
>>
>>Sysmod of database 'intro' abnormally terminated. 
>>-- 
>>Jukka Hartikainen                       *
>>Jyv{skyl{n yliopisto / laskentakeskus   *
>>Seminaarinkatu 15                       *
>>SF - 40100 JKL, FINLAND                 *
>
>I think you had a previous sysmod terminate abnormally.  If so, you may
>have a table called iirtemp left around.  When some system catalogs are
>modified, the work is done in a temporary table, iirtemp, deleted at the end
>of the modify.  If iirtemp already exists, modify is confused.
>$sql "+U" dbname -u$ingres
>help table iirtemp;\g
>		       if iirtemp exists, drop table iirtemp;\g 
>
>Ken Weiner, Ingres Technical Support, Alameda
>


 Yes,  iirtemp really exists. I can see it with help table but when I'll drop it
 I get error:

 1>drop table iirtemp
E_RD0060 Cannot access table information due to a non recoverable DMT_SHOW
    error
    (Tue Sep  1 07:34:49 1992)

E_DM0075 Invalid attribute record read while attempting to open a table.
    (Tue Sep  1 07:34:49 1992)

E_SC00206 An internal error prevents further processing of this query.   
    Please contact...

So...?
---
Jukka Hartikainen                       *
Jyv{skyl{n yliopisto / laskentakeskus   *
Seminaarinkatu 15                       *
SF - 40100 JKL, FINLAND                 *

Newsgroups: comp.databases.ingres
From: root@candle.uucp (Bruce Momjian)
Subject: Mapping Prev/Next page in 4GL table field
Organization: a consultant's basement
Date: Thu, 3 Sep 1992 14:08:17 GMT
X-Newsreader: Tin 1.1 PL5

I have found that the frs key mapping for next/prev page within a table
field does not work if the table field is not display only.  

		set_forms frs (	map(frskey20) = 'pf25',
				map(frskey21) = 'pf26');

This works only if the field is dislay-only.  

Has anyone gotten this to work?

-- 
Bruce Momjian                      |  830 Blythe Avenue
root%candle.uucp@bts.com           |  Drexel Hill, Pennsylvania 19026 
                                   |  (215) 353-9879(w)  853-3000(h)
Newsgroups: comp.databases.ingres
From: jabbate@Ingres.COM (Joe M. Abbate)
Subject: Re: Automatic Rule Generation Software
News-Software: VAX/VMS VNEWS 1.4-b1  
Organization: ASK Computer Systems, Ingres Product Division
Date: 31 Aug 92 19:05:56 GMT

In article <1992Aug26.214537.3589@schaefer.math.wisc.edu>, 
horn@schaefer.math.wisc.edu  writes...

>Does anyone know where I might be able to find a program that takes enhanced
>SQL create table statements and uses them to generate real SQL statements
>to create tables and the rules on those tables that preserve domain and
>referential integrity?  (By rules I mean those that run under Ingres/
>Knowledge)  
> 
>I have found rules to be very useful in my work, but creating all the
>rules needed for even a medium size set of tables can be a lot of work.

One of our customers in Brazil, with tables in the hundreds and concerned
about database integrity, developed a 4GL app that is used to specify
primary and foreign keys and then to generate rules.  If you are 
interested, I can help you get in touch with them.

Joe
----------------------------------------------------------------------
Joe M. Abbate
Ingres - Latin America
jabbate@ingres.com
Newsgroups: comp.databases.ingres
From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
Subject: Re: f8 data type problem
Organization: 
Date: Wed, 2 Sep 1992 20:32:53 GMT

In article <01GO9S14IGAA8WW4P1@ET.TUDelft.NL>, C.A.L.Herremans@ET.TUDelft.NL 
(Cornel Herremans) writes:
> Copying out a table with the -c flag (portable format) to transport
> a table from one database, 6.3/02 (vax.vms/02), to another database,
> 6.4/01 (vax.vms/00) caused a problem with large numbers with the
> f8 format. To check if the transport of the tabel was successfull 
> I calculated the total in both tables of a f8 field and discovered
> a difference, (first total: 4878560806.000, second total: 4878530388.000)
> The solution was to copy out the table without the -c flag, Ingres will
> then use a binary format and there were no problems to transport the table.
> 
> Question: 
> When I really want a portable format (e.g. to transport a table to
> another database on another platform) what has to be done to make this work
> right?

You'll never be able to make it completely portable because different
platforms may have different (and incompatible) internal representations
for floating point numbers.  Different representations imply different
precisions as well, so calculations performed on one platform (e.g.,
summing a column) won't necessarily match those on another.

You may be able to get some improvement (i.e., get closer agreement) by
using the "-f8" flag on the SQL command when you invoke the scripts
created by copydb.  For a column called "x" of type "f8" in a table
called "t", copydb creates a statement like this:

	copy t ( x = c0nl , nl = d1 ) into 't.dat' ;

If you invoke this script with "sql -f8N100.50 dbname <copy.out", then
the ASCII value will be of width 100 with 50 digits after the decimal
point.  To quote from the SQL Reference Manual:

    The default display format for both f4 and f8 is n10.3, unless your
    computer supports the IEEE standard for floating point numbers, in
    which case the display format for f4 and f8 is n11.3.

I discovered this flag by close examination of the scripts created by
the "unloaddb" command, which use 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.
Ich bin ein Virus.  Mach' mit und kopiere mich in Deine .signature.
From: ageorge@ra.nrl.navy.mil
Newsgroups: comp.databases.ingres
Subject: TEST
Date: 27 Aug 92 16:25:28 GMT
Reply-To: ageorge
Organization: Naval Research Laboratory, Washington DC
News-Software: VAX/VMS VNEWS 1.3-4

This is a test...please ignore...... 
Newsgroups: comp.databases.ingres