HDTenEightyP/NetNews huggingface dataset:
From: cathys@Ingres.COM (Cathy Savino)
Subject: Re: Windows 4GL problems (screen refresh)
Reply-To: cathys@ingres.com (Cathy Savino)
Organization: Ingres, An ASK Company
Date: 6 Oct 92 19:00:05 GMT

What your seeing may be the result of a bug that existed on versions previous to
the currect production release of w4gl version 2.0. Setting the bias on
any individual field in a composite field, caused the entire compisite to
be redrawn. This should only happen when you are changing the visbility
of an object within the composite field. Changing the bias to something
like FB_LANADABLE from some other visable bias should not cause this to
happen. This is fixed in w4gl version 2.0/01, which is out on VMS,
SUN4 and HP8. What version of w4gl are you running? If you are on one
of the paltforms I mentioned, you can get this release.

In article <1992Oct6.130805.689@rcc.de>, bernward@rcc.de (Bernward Averwald) writes:
|> After converting my Windows 4GL application for running on
|> multiple platforms (see Programmers Guide for INGRES/Windows 4GL:
|> Creating a Portable Form; that is grouping fields to stack/matrix fields), 
|> I have some problems with the number of screen refreshs after 
|> event blocks.
|> The form is updated several times after an event block is executed.
|> I suppose that the form gets an refresh event after every event block,
|> even after user events that are triggered by other event blocks.
|> Now my question: how do I disable unnecessary screen refreshs?
|> 
|> Any help is appreciated!
|> 
|> Bernward
|> -- 
|>         Bernward Averwald, Heinrichstr. 42, 4600 Dortmund 1, Germany
|>         Voice: +49 231 144048, FAX: +49 231 144047,  email: b@rcc.de
|> 	               Der mit dem Golf fdhrt.

Opinions: Mine, Mine, Mine!!!
--
Cathy Savino 
   ___     _____   __  __       Ingres, An ASK Company
  / _ \   / ____\  | |/ /       1080 Marina Village Parkway
 / /_\ \  \____ \  | |\ \       Alameda, Ca 94501
/_/   \_\ \_____/  |_| \_\      (510) 748-3524
                                cathys@ingres.com
Newsgroups: comp.databases.ingres
From: Jacob.Solomon@Corp.Sun.COM (Jacob Solomon)
Subject: Re: Ingres 6.4 and the Sparc 10
Organization: National Radio Astronomy Observatory
Date: Mon, 28 Sep 1992 19:18:47 GMT


To use viking/SS10 you need SunOS 4.1.3.

The previous version of SunOS had a built-in limitation in the amount
of kernel space available for tables, which resulted in a trade-off
between the amount of physical memory and the number of processes
supported by a kernel. In short, if you built a kernel that had large
process tables, and tried to boot it on a machine that had very large
physical memory, the kernel would crash.

Solving this problem required changing the amount of virtual space
reserved for the kernel; the space has been doubled - from 128 to 256
megabytes. While there is still an interaction between the physical
memory size of the machine and the size of the process tables, that
interaction is well above other limiting factors.

This means that kernels configured with MAXUSERS ratings of up to 225
can be booted on all supported memory sizes, using SunOS 4.1.3.
However, the base location of the kernel has changed; this also
changes where the user process stack ends up, and where shared
libraries get mapped.

I suspect that this is why Ingres doesn't work on SS10 with 4.1.3. The
good news is that there seems to be a solution. To fix this problem set
the following before startup:

ingsetenv II_LG_MAP_ADDR 10000000

Cheers
Jacob

----- Begin Included Message -----

From Tim.Read@UK Thu Sep 17 07:43:52 1992
Date: Thu, 17 Sep 92 15:43:03 BST
From: Tim.Read@UK (Tim Read - Sun Edinburgh - Senior Systems Engineer and Database Ambassador)
To: database@thedoor.corp.sun.com
Subject: FYI: Ingres 6.4/01 and 4.1.3
Content-Length: 224
X-Lines: 12
Status: RO

Hi,

I have just had a tape from Ingres for a demo and they have said that
Ingres 6.4/01 will work with an SS10 and 4.1.3 as long as you do the
following before startup:

ingsetenv II_LG_MAP_ADDR 10000000

Regards,

Tim
---


----- End Included Message -----
Newsgroups: comp.databases.ingres
Subject: Re: Suche Ingres/Windows4GL Programmierer in Dortmund
From: nick@manasys.co.nz (Nick Ivanov)
Date: 28 Sep 92 14:33:17 GMT
Distribution: comp.databases.ingres
Organization: Mana Systems Ltd., Auckland, New Zealand.


On 23 Sep 92 14:36:07 GMT,
Raghu=Ram%Supplier%IM=Hou@bangate.compaq.com said:
Raghu> Sender: root@nrao.edu (Operator)

Raghu> Could someone translate this posting so that many of us who could 
Raghu> not comprehend, try to help the desparate soul if he / she is 
Raghu> really in need of something urgently !!

Raghu> Regards,

Raghu> R.Raghu Ram

Raghu>    -------------------------- [Original Message] -------------------------      

Raghu> An alle Dortmunder (und Umgebung) !

Raghu> Wer hat Programmiererfahrung unter Ingres/Windows4GL?
Raghu> Unternehmer sucht jemanden, der ihn in das System einarbeitet, 
Raghu> bei guter Bezahlung.       

Raghu> Systemumgebung:

Raghu> IBM R6000 / AIX 3.2
Raghu> Ingres 6.4

Raghu> Interessenten bitte melden unter Tel.: 0231/818154
Raghu> Herrn Bohlmann verlangen.


To all people from Dortmund (and the surrounding region) !

Does anyone have Ingres/Windows 4GL experience?
An entreprenneur seeks someone who will familiarize him with
the system in return for a good reward.

The environment
IBM R6000 / AIX 3.2
Ingres 6.4

Interested parties should ring 0231/818154 and ask for Mr Bohlmann


Hope this helps
Nick :-)
--

################################################################################
# ::   ::                                                    Nick Ivanov       #
# :::::::   ::::    :: :::    ::::     ::::   ::  ::   ::::  Consultant        #
# :::::::      ::   ::   ::      ::   ::      ::  ::  ::     Mana Systems Ltd. #
# :: : ::   :::::   ::   ::   :::::    ::::   ::  ::   ::::  P.O. Box 34-137,  #
# ::   ::  ::  ::   ::   ::  ::  ::       ::   :::::      :: Auckland 10,      #
# ::   ::   ::: ::  ::   ::   ::: ::  :::::       ::  :::::  New Zealand.      #
#                                              ::::                            #
#       Ph +64-9-4190046, Fax +64-9-4192330, E-mail nick@manasys.co.nz         #
################################################################################
Newsgroups: comp.databases.ingres
From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
Subject: Re: cloning a database
Organization: 
Date: Thu, 1 Oct 1992 16:16:26 GMT

In article <1992Sep29.140353.1@gsbacd.uchicago.edu>, cs_mj@gsbacd.uchicago.edu 
(Mark Jaeger) writes:
> In article <1992Sep29.135401.7778@news.columbia.edu>, 
> alan@curta.cc.columbia.edu (Alan Crosswell) writes:
>> Is there any way to use a checkpoint of a database to clone it?  
>> ...
> ...
> Try creating a new, empty database with the new name, owner, and
> location(s).  Now shut down INGRES and use the tar file to populate the
> data directory for the new database with everything _except_ the
> configuration file (aaaaaaaa.cnf in the primary data directory for the
> new database).  I.e., overwrite all the *.t00 file that are already
> there for the empty database.

A friendly person at Ingres has pointed out to me that my method _almost_
works.  It's okay, as long as you don't want to create any new tables,
views, or indexes in the cloned database, ever.

The problem is, that when you create a new table, index, or view, INGRES
stores a row in the iirelation table with an integer key in the reltid
and reltidx columns, and the base value from which this key is generated
is stored in the configuration file.

The new, empty database has a low value for this key, but the implied
value in the cloned database is bigger (due to it's having more tables). 
It turns out that if you follow my procedure and then create a new table
in the cloned database, it may very well write over the file for an
existing table, thereby corrupting data in the cloned database.

The amended procedure calls for running "infodb" on the original
database and looking at the field called "next table id".  After you
create the new, empty database, repeatedly create and drop a table until
the "next table id" (as shown by "infodb" on the empty database) matches
that of the original database.  _Now_ you should be able to shut down
INGRES and copy the files from the checkpoint (tar file or backup save
set) into the data directory, and creating new tables or indexes in the
cloned database won't corrupt any data.

Thanks to the person from Ingres who notified me of this problem.  I
guess he/she wanted to remain anonymous, or he/she would have posted it
here him/herself.

--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: veit@Unify.com (Veit Irtenkauf)
Subject: Re: Suche Ingres/Windows4GL Programmierer in Dortmund
Organization: Unify Corporation (Sacramento)
Date: Tue, 6 Oct 92 00:40:43 GMT

In article <BvG9oE.3F0@usenet.ucs.indiana.edu>, mdchaney@fractal.ucs.indiana.edu (M Darrin Chaney) writes:
> Raghu=Ram%Supplier%IM=Hou@bangate.compaq.com writes:
> >Could someone translate this posting so that many of us who could 
> >not comprehend, try to help the desparate soul if he / she is 
> >really in need of something urgently !!
> 
> I think you're just curious :)
> 
> Seriously, though, if the desparate soul was that desparate, don't you think
> he'd have had someone translate it into English, also?  He's looking for a
> Ingres/W4GL programmer.  I assume that it's in German because he'd like
> someone who knows German.
> 

Although I don't know whether there's a town here in the States called
Dortmund (I know I should know), the fact that he writes in German and
looks for someone for a job in Dortmund convinced me that it is in 
Germany

-- Veit


-----------------------------------------------------------------------
Veit Irtenkauf    Technical Marketing Manager  |  email: veit@unify.Com
Unify Corporation                              |  voice: (916) 928-6322
3901 Lennane Drive, Sacramento, CA 95834-1922  |    fax: (916) 928-6406
Newsgroups: comp.databases.ingres
From: DELFT UNIV OF TECHNOLOGY/COMP CENTRE +31 15 784821 <Jan.vanSetten@RC.TUDelft.NL>
Subject: Re: Destroydb and checkpoints warning
Organization: National Radio Astronomy Observatory
Date: Mon, 5 Oct 1992 10:52:15 GMT

>> I discovered that the destroydb command to destroy an entire database
>> does not only destroy your database but your checkpoints too!
>> So accidentally destroying the wrong database is a large problem
>> because you lost your backups too.

>This is a warning that is definitely worth repeating.  

So, here I like to repeat ...
I'm completely agreeing with Eric and Mark.
I talked about this Ingres behaviour with ASK TS fellows.
If I understood them well, their meaning was that "a good DBA/ISA should
not and would not make mistakes".

Okay, destroydb has a dialogue option (-p) indicating that you want
to be asked if you are sure. It is a pity it is not the _default_.

This is one of the reasons we are using UNLOADDB as a backup way, too.
Then all objects are out of the Ingres command regime.

Jan.

PS. On Sun Sparc with 6.4 we have nice results with compressing ckp files
and unload directories.

>----------------------------------------------------------------------<
 A. van Setten                   | post to:  Post Office Box 354
 Delft University of Technology  |           2600 AJ DELFT
 Computing Centre                |           The Netherlands
 Campus Ingres Support           | ship to:  Julianalaan 134
 Phone   :  +31 (0)15-78 4821    |           2628 BL DELFT
   "     :  +31 (0)15-78 5012    |           The Netherlands
 Fax     :  +31 15-78 3787       | visitors: Michiel de Ruyterweg 10-12
 E-mail  :                       | RC-
     Jan.vanSetten@RC.TUDelft.NL | Helpdesk: Info@RC.TUDelft.NL
>----------------------------------------------------------------------<

========================================================================
Newsgroups: comp.databases.ingres
From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
Subject: Re: Destroydb and checkpoints warning
Organization: 
Date: Fri, 2 Oct 1992 19:11:55 GMT

In article <walraven.718015733@athena.research.ptt.nl>, 
walraven@athena.research.ptt.nl (Walraven H.G.) writes:

> I am using the Ingres checkpointing mechanism for database backup.
> Because my databases are not very big (< 50 Mb) I do my checkpointing
> to another disk instead of tape.
> 
> I discovered that the destroydb command to destroy an entire database
> does not only destroy your database but your checkpoints too!
> 
> So accidentally destroying the wrong database is a large problem
> because you lost your backups too.

This is a warning that is definitely worth repeating.  

I remember reading somewhere (the DBA Guide?) that checkpoints should
not be considered a replacement for regular operating system backups. 
So although it's probably not necessary to backup the INGRES data
directories, it _is_ useful to make backup copies of disk checkpoints.  

Our checkpoint scheme involves several steps: 

1. Check the backup date on the last checkpoint to see if it has been
backed up to tape.  If so, then flush it.

2. Run sysmod on the database.

3. Check to see that there is enough free space on the checkpoint disk
to take a fresh checkpoint.  INGRES isn't very graceful about what it
does when it fills up a disk during checkpoint--it leaves a partial
(hence useless) checkpoint, and leaves the disk full.

4. Connect to the database and do "select * from iifile_info".  This
makes it much easier to go back and recover a single table by hand, if
need be.

5. Issue the ckpdb command.

--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: gnb@duke.bby.com.au (Gregory N. Bond)
Subject: Re: termcap files with INGRES
Organization: Burdett, Buckeridge & Young, Melbourne, Australia
Date: Mon, 28 Sep 1992 02:35:58 GMT

>> On a Unix system, even though my termcap file specifies the number of
>> lines and number of columns for my screen, I can override this by setting
>> environment variables for these parameters.  Does Ingres have a similar
>> method to override the number of lines/columns in the ii_termcap file by
>> setting logical variables in VMS (or environment variables in Unix).

What is worse (at least under Unix, don't know about VMS) is that
there was no way to tell Ingres about the size of your screen if you
were using xterms or whatever.  You needed a different termcap entry
for each possible size of terminal.  (Real applications, including the
system termcap and Ingres 5 (!), use an ioctl on the tty to get the
device size).

An undocumented change in the 6.4/02/00 release on Sun4s is the :wx:
termcap flag.  This tells Ingres to look at the terminal driver for
window size, just like V5 used to do!  (I only noticed this by doing a
diff on the 6.3/01/02 and 6.4/02/00 termcap files).

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: alan@curta.cc.columbia.edu (Alan Crosswell)
Newsgroups: comp.databases.ingres
Subject: Summary: "Table xxx is either not a view or its definition is unavailable"
Date: 5 Oct 92 17:42:27 GMT
Article-I.D.: news.1992Oct5.174227.26232
Organization: Columbia University

First, thanks to all of you who responded regarding this error.  The
"table xxx is either not a view or its definition is unavailable" error
is the result of a table being created, journaled, a view created, and the  
table dropped.  The database is then restored from a checkpoint and journals  
with rollforwarddb.  This "plays back" the creation and dropping of the table  
but does not properly play back the necessary side-effect of dropping a table  
which is dropping a view based on that table.  So, the view stays around --  
sort of.

One can find out about these half-existing views by running VERIFYDB (use  
-mreport) and can try to fix them with it too.  One can also go in with the +U  
switch and delete appropriate rows from iirelation and probably some other  
tables.  I used this method as a short term expedient since VERIFYDB -mrun  
aborted and I was too scared to run VERIFYDB -mruninteractive after seeing the  
nasty warning message:-)  It flagged a bunch of other errors include optimizer  
stats existing for non-existent base tables (I suspect for the same reason as  
the twilight zone view).  I will probably do the -mruninteractive and see what  
happens soon.
/a
Newsgroups: comp.databases.ingres
From: sriram@tcs.com (Sriram Srinivasah)
Subject: Large databases
Organization: Teknekron Communications, Inc
Date: Thu, 1 Oct 1992 16:18:10 GMT

Hi,

I was wondering if anyone has had trouble with fairly large databases using
Ingres 6.4 on a Sun SparcStation 2.

My parameters are ...

table 1  ..........      300,000 records, 1/2 Gigabyte, 200 columns
table 2  ..........      10 million records, each 30 bytes

The kind of areas I need clarification on are ....

1. If I create an index on table1 for a couple of columns, do I need to greatly
    increase swap space on the workstation?

2. What kind of adminstration problems do you run into, for such large databases?
   What steps have you taken?

3. It'd be nice to have some ballpark figures of performance ("selecting 1 item out
   of 10 million records of x size took Ingres 40 seconds")

Forgive my naivete.

Sriram
(sriram@tcs.com)
Newsgroups: comp.databases.ingres
From: raghu@enh.nist.gov
Newsgroups: comp.databases.ingres
Subject: is ingres a pd software??
Date: 29 Sep 92 20:17:00 GMT
Organization: NIST

is ingres a pd software??
if so where can we get it from and what other info can you give me.
thanks and I will appreciate your response.
raghu@enh.nist.gov
From: alan@curta.cc.columbia.edu (Alan Crosswell)
Newsgroups: comp.databases.ingres
Subject: hyphens not allowed in Unix usernames in Accessdb
Date: 6 Oct 92 15:33:30 GMT
Organization: Columbia University

We just tried to add a Teaching Assistant userid as an Ingres user with
accessdb.  Our ta userids look like ta-xxx.  Accessdb wouldn't allow a
userid containing a hyphen, although it is legal in Unix.  Is there any
workaround?  I know that in pre-version 6, it was fairly simple just to add  
users to some system table and it was even documented that way.  I'm not sure  
this is still doable and whether the hyphen in the userid will break other  
stuff.  Anybody have experience with this?
/a
Xref: sparky comp.databases.ingres:1502 comp.unix.programmer:4835
From: chris@visionware.co.uk (Chris Davies)
Newsgroups: comp.databases.ingres,comp.unix.programmer
Subject: Catching division by zero
Date: 1 Oct 92 08:58:57 GMT
Organization: VisionWare Ltd., Leeds, UK
X-Newsreader: Tin 1.1 PL5

I'm using C with embedded SQL (Ingres 6.4/01 on Sun4 SunOS 4.1.2).

The problem I've got is that Ingres doesn't warn me when I get an
integer division by zero error in a SELECT statement, it just returns
0.  (The floating point stuff returns 0.Inf - an IEEE representation of
infinity.  Yuk!)

For example, "SELECT 1/0" shows this problem (you can try it in sql or
isql too).

After speaking with a member of Ingres Technical Support, who logged an
enhancement request for me, they pointed out the '-xw' flag for the sql
and isql terminal monitor applications.  (This flag terminates queries
with /0 and generates an error - just like I would have expected in the
first place.)

Now for the question.  Can anyone explain to me _how this flag works,
and if so, how could I go about implementing this kind of error
handling in my code?

Ta,
Chris
--
            VISIONWARE LTD, 57 Cardigan Lane, LEEDS LS4 2LE, England
  Tel +44 532 788858 x238.  Fax +44 532 304676.  Email chris@visionware.co.uk
---------- "VisionWare:   The home of DOS/SQL/UNIX/X/VMS integration" ---------
From: rfrx@vax5.cit.cornell.edu
Newsgroups: comp.databases
Subject: How fast is Postgres overall?
Date: 29 Sep 92 16:21:41 EDT
Distribution: comp
Organization: Cornell University

How quick is Postgres?  I simply need to know if it is much slower than any
other standard database.  A rough description is fine.  Our group will be
storing about 10,000 records with a total of about 40,000 to 400,000 data
elements total (so 4 to 40 or more data elements per record).  We're thinking
of running Postgres (4.0.1) on DECstations.

Anthony K. Yan
RFRX@vax5.cit.cornell.edu
SIDEV group

Newsgroups: comp.databases
From: durai@ORTTA (Appadurai V.)
Subject: Re: We need dBaseIV help!
Organization: U of Mn
Date: Mon, 28 Sep 1992 21:59:05 GMT

reply to <1992Sep28.163538.1@ulkyvx.louisville.edu> cl130000@ulkyvx.
louisville.edu :

I am not a dbaseIV user.. (am from the fox camp)
(in case no dbase guru replies, you may want to consider my response)

dMouse:  I think version 1.5 supports mouse, not earlier ones
         Nothing has to be done to activate the mouse.  Make sure your mouse 
         properly connected and mouse driver loaded.  Of course, there 
         should be a "set" command too..(set mouse on), in case you don't 
         get the mouse cursor.

null date: Braces should do the trick (it does in fox.. you may want to try)
           eg: tdate = {}  
           the variable tdate now has null value

suppress age: I did not understand your posting.  If users don't want to 
              mention their age, don't make the field mandatory.  On the 
              other hand, if you have the data, do not display the data on 
              screen. 
              If I have not answered your question, may be you can 
              send more specific information as to how you want the data 
              displayed/hidden.
From: michaelh@g2syd.genasys.com.au (Michael Haldey)
Newsgroups: comp.databases
Subject: Re: Clipper 5.01 & Turbo C++
Date: 29 Sep 92 06:04:18 GMT
Organization: Genasys II, Sydney, Australia

In article <1a751qINNkdd@usenet.INS.CWRU.Edu> ch966@cleveland.Freenet.Edu (Jose M. Febus) writes:
>
>Hi...
>	I want to know if i can use Turbo C, Turbo C++ or 
>Borland C++ 3.1 . I don`t have Microsoft C and i don`t
>want to buy it...
>	any advice???
>	thanks...
>
>	Jose Febus
>-- 
>	Jose Febus
>	"Drinking at Yagrumo"

No you can't. You can't even use MSC 6.0 and higher. The problem is 
that Clipper supports MSC 5.1 only. You need to order downgrade kit for 
MSC 6.0. New Clipper 5.x will support MSC 6.0.
Borland Compilers have different floating point convention. There are also
some other differences that make using Borland Compilers impossible.

michael
-- 
Michael Haldey  |  Genasys II Pty Ltd
                |  13th Level, 33 Berry St, North Sydney, NSW, Australia
                |  Phone:    +61-2-954-2878 (-9930 FAX)
                |  Internet: michaelh@g2syd.genasys.com.au