HDTenEightyP/NetNews huggingface dataset:
From: dtodd@titan.ucc.umass.edu (David M. Todd)
Subject: Re: Changes in Advanced Revelation from 1.16 to 3.0
Organization: University of Massachusetts, Amherst
Date: Thu, 12 Nov 1992 12:57:34 GMT


While I agree that the tradeup process from 1.x versions of Revelation
to 3.0 is complex, I think RTI has handled it pretty well.   I would
like to see some processes more automated (e.g. updating dictionary
MSTR fields, changing column names in windows) and some code provided
for evaluating changes needed in existing code and making some of the
easier changes (changing column names in braces and xlates).  However,
many of these changes are necessary only to optimize the application,
not to run it under 3.0.  You can handle the new file/table names by
setting up aliases and there is no requirement, for example to use
SOURCE rather than a BP file.  Sure, I would haved *loved* an easier
tradeup, but I decided a long time ago I wouldn't give up the power of
Revelation for easier use, and the tech support has been good.


|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ David M. Todd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
|Department of Psychology, University of Massachusetts, Amherst, MA 01003 USA|
|Phone: 413/545-0158 ___ <DTodd@Titan.ucc.UMass.EDU> _____  Fax: 413/545-0996|
Newsgroups: comp.databases
From: dtodd@titan.ucc.umass.edu (David M. Todd)
Subject: Re: Changes in Advanced Revelation from 1.16 to 3.0
Organization: University of Massachusetts, Amherst
Date: Thu, 12 Nov 1992 12:59:38 GMT

In article <1992Nov12.074317.10382@u.washington.edu> someday@hardy.u.washington.edu (Scott Johnson) writes:
>There are some patches to the upgrade process and a 3.01 upgrade to the 
>main product available on the Revelation CompuServe forum.  Or give tech
>support a call, they can get them to you.

What does the 3.01 upgrade include?


|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ David M. Todd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
|Department of Psychology, University of Massachusetts, Amherst, MA 01003 USA|
|Phone: 413/545-0158 ___ <DTodd@Titan.ucc.UMass.EDU> _____  Fax: 413/545-0996|
From: tleylan@pegasus.com (Tom Leylan)
Newsgroups: comp.databases
Subject: Re: Clipper 5.01 left over locks
Date: 8 Nov 92 21:31:29 GMT
Organization: Pegasus,  Honolulu

paulb@cs.man.ac.uk (Paul Bean) writes:

>I presumed that the lock information was
>held in the dbfs so I deleted these and went to a backup.  However
>when I tried to run the program it still wouldn't let me open the
>previously locked files.

Paul:

Well I'll admit that I could be wrong but I'm "sure" that file locks
aren't "physical" and in any case they wouldn't be stored inside a file
or it would distort the file (you'd have to know where it was and skip
over it i.e. read past the lock) and that just isn't done.

At worst lock info would be kept in the directory entry but I'm "sure"
that isn't the case also.

These things should all be implemented logically (not physically) so any
lock would be released when the power went off (on a network it might take
a little while until the network noticed that the process who had the lock
is no longer running) but it can't be permanent.

What is the exact message that you're getting when you try to re-run the
application ?

tom
From: MICHAEL.WILLETT@OFFICE.WANG.COM ("Michael Willett")
Newsgroups: comp.databases
Subject: PACE for open systems, client/server development
Date: 12 Nov 92 14:15:56 GMT
Organization: Mail to News Gateway at Wang Labs

I'll be happy to send copies of that PACE RDBMS for open systems
systems client/server development environment announcement
from Technetron to people who aren't able to go this week.

Michael.Willett@OFFICE.Wang.com
Newsgroups: comp.databases
From: "tom frazer" <tom.frazer@canrem.com>
Subject: dbase iii+ vs. dbase iv
Reply-To: "tom frazer" <tom.frazer@canrem.com>
Organization: Canada Remote Systems
Distribution: comp
Date: 13 Nov 92 02:02:35 EST


======\ Quoting: DEBBY MORLEY \======\ On: 11/11/1992 \===========

DM> I am curious as to why so many people have held onto and prefer dbase I
DM> the newer dbase IV.  Can someone please summarize the differences in th
DM> two (DOS) products for me?

======================================\ END QUOTE \======================

    Tons of new commands and some people don't want to learn them?

    I have upgraded every step from III+ and vastly prefer the new features.
    While dBASE IV 1.0 was a buggy memory hog, I had no problems with 1.1
and 1.5 is even better, though I wish they had allowed the TEDIT
(external editor) command to swap dBASE to disk the way the RUN() function
does, but at least you can set up a hot key to do that.
---
 . MegaMail 2.10 : Toronto Blue Jays 1992 World Series CHAMPIONS!
--
Canada Remote Systems  - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044
Newsgroups: comp.databases
From: freyder@NeoSoft.com (Rob Freyder)
Subject: Clipper S'87 TO 5.01a - Have You Done It ???
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Fri, 13 Nov 1992 12:35:15 GMT

Greetings Folks, I am posting this for a friend, if you want to followup that
is just fine as he reads news but cant post. If you want to mail a reply
please send to arthur@marley.aws.waii.com

************* Clip here ****************

I am at the end of a long Clipper Summer '87 development cycle and have 
started to look into the 5.01a release of clipper.  I wonder how many 
people have decided to make the LEAP into "CA Land" ?? 
Trying to adopt the next generation development platform with all the various
choices available today is VERY CONFUSING!! (FoxPro, SuperBASE, Code BASE C++,
 etc.) 
The technologies I would like to get involved in more of include:

1. SQL Client-server support built into clipper's xbase language.
2. C++ "hooks" / Object Oriented Development
3. UNIX platform compatibility
4. Multiple GUI, single GUI library.... (Graphical DOS, UNIX Motif, MSC Windows)

Must be Royalty FREE, and continue DBF file support....

I am aware that Clipper 5.01a has item #2 somewhat well scoped out, but all the
other items are not there yet... Also, xbase programming and SQL client server 
are somewhat opposing ideas is it not ??? One assumes open dbase files, the 
other working cursor sets of queried results from the server... Can these 
technologies co-exist nicely ?? 

Other questions to you are :

1. Did you migrate to Clipper 5.01a from S'87 ?? Were you able to produce 
"industrial strength" applications in EXE format just like good ole' S'87...?
What about all the nasty rumors about 5.01a crashing all over due to internal 
memory conflicts, etc....

2. Did you switch from Clipper Summer '87 to some other product besides 5.01a ??
Why and again, were you able to deliver robust software..... ?? 

3. How many issues, compared to the list I mentioned above, were of concern to
 you when you selected your "next generation" dev platform..... 

Please email your responses to: "arthur@marley.aws.waii.com"
BTW
Our internet connection is funky -- it is down nights and weekends! So if mail
bounces back to you, please re-send them.  I will confirm receipt and 
post a summary on the net  for all interested......  THANK YOU !

arthur 8^)
Houston, Texas
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Freyder        "These comments are my own" -me

Daytime: rob@marley.aws.waii.com    Evening: freyder@neosoft.com
Newsgroups: comp.databases,comp.databases.ingres
From: thompson@stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
Subject: Ingres questions
News-Software: VAX/VMS VNEWS 1.4-b1  
Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics
Distribution: usa
Date: Tue, 10 Nov 1992 21:37:00 GMT

I'm currently in the market for a Unix SQL database, and one of the products
I'm considering is Ingres.  I have a couple of questions about it.  (Please
E-mail or post any replies to comp.databases.  I don't currently read
comp.databases.ingres.)

First of all, I understand that Ingres has a limit of ~2000 bytes per record.
I know they have a way to incorporate large text fields in the database, but
what about the situation where one just has a large number of different fields,
none of which is large by itself, but the total sum is greater than 2000?  The
salesman claimed this wasn't a problem, but he couldn't explain why.  Has
anybody run into this problem, or know of a way to get around it?  Is it a real
problem with Ingres?

What about importing and exporting text files?  This is something that's going
to be important for us.  Are there any limitations involved with Ingres and
importing/exporting text files?  Are there problems doing this in a VMS
environment?

Another question I have is about row level locking.  Somebody I was talking to
claimed that Ingres does not have row level locking.  However, since his only
real experience is with the old public-domain version, I'm somewhat dubious
about this claim.  Is this true, or just a rumor?

Thank you,

Bill Thompson
Newsgroups: comp.databases
From: troj@cwis.unomaha.edu (Kevin Trojanowski)
Subject: Re: Paradox 4.0 speed (?)
Organization: University of Nebraska at Omaha
Date: Fri, 6 Nov 1992 22:35:39 GMT

tim@tim.src.utah.edu (Tim Ma) writes:


>Two questions regarding Paradox:

>1)  Paradox 4.0

>An inquiry to all users of Paradox 4.0 out there.  We recently upgraded to 
>4.0 after reading articles and ads that highly touted the improved speed of
>Paradox 4.0 (claims that it was much faster that FoxPro 2.0).   I am 
>impressed with some of 4.0's new features, but SPEED is does not seem to be
>one of them.  I have a simple script written in 3.5 that randomizes the order
>of records in a file.  All it does it import that file as a single TEXT 
>field, tacks on a random number in anothe field, sorts on the random number, 
>and then outputs the randomized file.  To my surprise, it runs almost 50% 
>slower in 4.0 thanit did in 3.5 (14 minutes vs. 10 minutes).  I'm running a
>386SX with 4M of RAM.  Any ideas or comments?

Wait now...  When you say you're doing a sort on the data, does this mean
that you're performing a sort in PAL, or that you're incrementally updating
the index?  If you're incrementally updating the index, do you really need
to?  You could more than likely improve your performance by updating the index
only when you're done with all your insertions.

>2)  Paradox 3.5 "paradox.net" file

>Most of our users are still using 3.5 during our transition.  Does anyone 
>know what exactly Paradox does to the paradox.net file?  When we get up to
>around 10 users or so, it can take almost 4-5 excruciating minutes just to 
>pull up Paradox.  A file server console check shows that stations are placing
>an "exclusive lock" on the paradox.net file.  Granted some of our machines 
>are 8088's but this wait seems almost ridiculous.  Is there anything I can
>do to help speed up the process?

Can't help you there -- I only use Paradox at home, and thus haven't ever
tried it on a network.

>Thanks,

>Tim Ma
>Associate Programmer
>University of Utah
>email:  tim@src.cppa.utah.edu


-------------------------------------------------------------------------------
-                                   "She had what it took: great hair, a      -
- Kevin Trojanowski                  profound understanding of strategic lip  -
- Internet: troj@cwis.unomaha.edu    gloss, the intelligence to understand    -
-      CI$: 70521,312                the world and a tiny secret interior     -
- US Snail: 1905 Thurston Ave, #8    deadness which meant she didn't care."   -
-           Bellevue, NE 68005                            -Douglas Adams      -
-                                                          _Mostly Harmless_  -
------------------------------------------------------------------------------- 
Newsgroups: comp.databases
From: joet@dcatlas.dot.gov (Joe Trott)
Subject: Re: PC Rbase Question
Organization: U.S Dept. of Transportation
Date: Thu, 12 Nov 1992 14:45:39 GMT

mnewson@memstvx1.memst.edu writes:

>I would like to know is there a way to convert a RBase table (version 3.0)
>to ASCII format and if so what are the commands?

Items in <> are parameters you supply...

OUTPUT <filespec>
UNLOAD DATA FOR <table> AS ASCII [sorted by...] [where...]
OUTPUT SCREEN

-JTT

From: thwaites@hpsgm2.sgp.hp.com (Damien THWAITES)
Date: Sun, 8 Nov 1992 10:59:58 GMT
Subject: HELP: Loading text file to FoxPro database
Organization: HP Singapore Notes-Server
Newsgroups: comp.databases


I have an ASCII text file that contains one field from a database per line.
As there are 20 fields in each record, there are 20 lines in the file for
each record. I want to load this text file into a FoxPro database with
the same number of fields (20) per record.

How can I read this text file into a FoxPro database ? I tried using the
APPEND FROM command but FoxPro loaded each line of the text file as a
separate record. I need FoxPro to place each of the 20 lines into the
corresponding database record field. Any pointers are much appreciated !!


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Damien Thwaites                           Tel    : (65) 279-8947
Information Technology Department         Email  : thwaites@hpsgm2.sgp.hp.com
Hewlett-Packard Singapore                 Fax    : (65) 279-2862
1150 Depot Road, SINGAPORE 0410.          HPDesk : Damien Thwaites /HP3200/09
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: CIR_TLW@VAX1.UTULSA.EDU (Tristia Watson)
Newsgroups: comp.databases
Subject: Database Publishing
Date: 12 Nov 1992 12:20:42 -0600
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu

Greetings!

I am trying to collect any and all information on the subject of "Database
Publishing" for a class.  If anyone has any insights on the industry,
businesses that are engaged in this type of activity or tips on where to
find more information, please (beg, plead, grovel...) send them to me.  I
would be entirely in your debt...at least until graduation!

    +---------------------------------------------------------------------+
    | Tristia Watson                              CIR_TLW@VAX1.UTULSA.EDU |
    | Client Support Coordinator                     HELP@VAX1.UTULSA.EDU |
    | Computing & Information Resources Help Desk        Phone:  631-3500 |
    +---------------------------------------------------------------------+
From: aaron@satco.UUCP (Aaron Pelton)
Newsgroups: comp.databases.informix
Subject: Informix 4GL arrays
Keywords: 4gl array scroll
Date: 7 Nov 92 20:19:25 GMT
Reply-To: aaron@satco.UUCP (Aaron Pelton,Colby Mansion)
Followup-To: pelton@uvm-gen.emba.uvm.edu
Organization: Saturday Company, Waterbury, VT


    In my quest for the answer to Informix vs Progress I've come across
a particular area, scrolling data on the screen, that Informix doesn't
seem to handle well.

   Given that I have a set of data that may be anywhere from 0 to n records
that I want to place in a scrolling region on the screen, can it be done
without a LOT of code to accomplish this?

   Arrays would solve the problem only I don't know ahead of time how big
it needs to be and it could be greater than several thousand records. (I
know, it's not likely, but Progress seems to do it naturally.....) Trying
it out I came up with just using INPUT, SCROLL and FETCHES. I use the
keyed data from the INPUT for updates so I have to close the cursor and
reopen it and so forth. I'm at 79 lines (w/ bugs still) and counting while
progress seems to be able to do it in about 10 lines. Sort of the reason
why we want to go to a 4gl......

   Can anyone recommend a direction to look for clues? Is it possible to
fool informix into using a malloc'd array?

   (Note: I admit it, I'm for informix but I have to convince the others of
the team.....)
-- 
Aaron Pelton		    | If it sounds like an opinion, it's probably mine.
aaron@satco.UUCP            | Only R. Crusoe could have it all done by Friday
{decvax,uunet}!virgin!satco!aaron
Newsgroups: comp.databases.informix
From: schiele@bernina.ethz.ch (Thomas Schiele)
Subject: Re: *** HELP - Index Locks are creating DEADLOCKS ***
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Mon, 9 Nov 1992 11:11:20 GMT

Informix: Locks and Indexes 
 
I've noticed the following points using Informix Version 4:
1. Even if you use the option 'LOCK MODE ROW' in the SQL statement 'CREATE
   TABLE', the database will use table locks! There is no row level
   locking. 
   Row level locking works only if you use an index on that table. 
2. If you delete a row, the next row in the index (!) will be locked too.
3. A row can be inserted only if the next tuple in the index (!) is not 
   locked.
   Row level locking works only if you use an index on that table. 
   
I've found in the complete documentation for Informix one (!) remark only:
   "A process running under Informix-OnLine acquires an exclusive 
   lock on a row before it updates a table, deletes a row, or inserts
   a row. A exclusive lock prevents another process from modifying the
   contents of the row before the lock is released. The delete process
   also locks the next, or adjacent key, value in the index. This
   feature ensures that another process does not insert a row with
   the same value as the deleted key until the lock is released. The
   insert process acquires an exclusive lock on the row and checks to 
   make sure that the next, or adjacent key, values are not locked. If
   the values are locked, then the insert fails." (Informix-OnLine
   Administrator's Guide)
 
My remarks:   
1. Row level locking works with indexes only. You have to use an index 
   even if you don't need it.
   It seems that locking is implemented via ISAM index locking. 
2. There are conflicts between insert and/or delete operations because   
   row level locks affect neighbour tuples in the index (side effect
   called 'feature'!). Deleting the last row in the index even locks 
   the index to the end, no more rows can be inserted.
3. There are no hints in the documentation which strategy to use for   
   defining an index in order to have correct row level locking.
   For example it is not defined, whether one must use all fields of
   all WHERE clauses (!) of a whole application (!!) to have correct row
   level locking. It is even not defined how locking works if there is 
   more than one index on a table.
 
>>Can anyone help:
...I need some help too (or is this really a 'feature' of informix?)...
 
 
cu Thomas
-----
Thomas G. Schiele
Winterthurerstrasse 297
CH-8057 Zuerich
Switzerland
schiele@bernina.ethz.ch
From: davek@informix.com (David Kosenko)
Newsgroups: comp.databases.informix
Subject: Re: Estimating sizes of indexes
Date: 11 Nov 92 15:17:31 GMT
Organization: Informix Software, Inc.

Jim Kunzman writes:
>Informix provides very useful tools for estimating sizes of rows in
>a table.  Perhaps I've overlooked it, but I can find nothing about
>estimating sizes for indexes.  In other words, given table X with
>indexes A, B, and C, how much overhead is required for each additional
>row in table X?
>
>Can this be done easily?  Is there somewhere in the documentation where
>this is covered?  Is there any difference in overhead for SE and Online
>(unfortunately, we have to support both)?

For OnLine, this is covered (in the Guide to SQL Tutorial, pg 10-16) under
Estimating Index Pages.   There is some difference between SE and OnLine -
to keep it simple, consider SE's "page size" to be 1K (since index "nodes"
are 1 page in OnLine and 1K in SE).  The resulting number is really an
approximation, since it is impossible to accurately predict b+tree
overhead without knowing how and when the keys were inserted, exactly how
many duplicates of each key (when applicable) etc., but it can get you
pretty much in the ballpark.

Dave
-- 
Disclaimer: These opinions are not those of Informix Software, Inc.
**************************************************************************
"I look back with some satisfaction on what an idiot I was when I was 25,
 but when I do that, I'm assuming I'm no longer an idiot." - Andy Rooney
From: aland@informix.com (Colonel Panic)
Newsgroups: comp.databases.informix
Subject: Re: defer interrupt.
Date: 8 Nov 92 02:52:46 GMT
Organization: Helen Keller Bondurant's Performance Driving School for the Blind

In article <5576@krafla.rhi.hi.is> gaukur@rhi.hi.is (Kristjan Gaukur Kristjansson) writes:
>I'm currently trying to figure out how to properly use 'defer interrupt'
>and 'options sql interrupt on' to stop sql queries.
>
>I know I have to check on int_flag everywhere but when I try to use it
>with 'foreach' loops then I don't seem to have much control over when
>it's detected.
>
>Are there any guidelines out there on the best use of this feature or
>something that helps me better to understand this.
>(F.ex. should I rather use open,fetch,close than foreach.  Shall I use it
>after every possible SQL-statement or just some.)

Did you read pages S-29 - S-32 (in the English version, anyway) of the 
4GL 4.1 Supplement document? If so, what was unclear?

>				With thanks in advance,
>					Kristjan Gaukur Kristjansson
>					gaukur@rhi.hi.is

--
Alan Denney      aland@informix.com      {pyramid|uunet}!infmx!aland
I says, "Earl, this hill can spill us 
         you better slow down or you're gonna kill us
         just make one mistake, and it's the Pearly Gates 
         for them 85 crates of U.S.D.A.-approved cluckers.
         You wanna hit second gear, please?"
                                  -- 'C. W. McCall', "Wolf Creek Pass"
From: billd@informix.com (William Daul)
Newsgroups: comp.databases.informix
Subject: Anyone interested in a Federal User Group?
Date: 10 Nov 92 07:44:09 GMT
Organization: Informix Software, Inc.
Originator: billd@cheetah

I had a couple of people contact me regarding a government Informix user
group.  None currently exists, but there seems to be some interest.  Are
any of the readership interested in such a group?  Send me a note it you
are.  Please include phone number, address, FAX, and email.

Thanks,  --Bill

-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 William Daul             Advanced Support      INFORMIX SOFTWARE INC.
 4100 Bohannon Dr.        (415) 926-6488 - wk
 Menlo Park, CA. 94025    uunet!infmx!billd  or  billd@informix.com
Newsgroups: comp.databases.informix
From: chriss@sam.amgen.com (Chris Silvester)
Subject: ISOLATION LEVEL...
Organization: Amgen
Distribution: usa
Date: Tue, 10 Nov 1992 00:29:58 GMT

Hi All...

I'm working with 4gl and Online and I was wondering if there is any internal
variable that indicates the current isolation level, or some other way of
checking the current isolation level.  Any help would be appreciated.

Thanks in advance,

Chris S.

Newsgroups: comp.databases.informix,comp.databases
From: pelton@satco.uucp (Aaron Pelton)
Subject: Informix 4GL vs Progress
Followup-To: pelton@uvm-gen.emba.uvm.edu
Summary: info desired on informix vs 4gl decisions
Keywords: informix 4gl progress database
Organization: Saturday Company, Waterbury Vt.
Date: Sat, 07 Nov 92 17:16:40 GMT

    I'm a member of a team assigned the task of choosing between informix
and progress. Is there anyone else out there who has already made the 
decision that might have encounted problems with either package that we
should know about?

    We have an eval copy of the informix 4gl product but found out about
their forms package after the we'd received it and we're running out of time.
Can anyone make any comments about how well it works? How about Progresses
FastTrack?

    We've been using Informix SQL and C for most of our work to date but
would like to reduce code maintenance and so forth.

    Replies to pelton@uvm-gen.emba.uvm.edu (should be reliable) or the
address below and if anyone would like to know the results, fire off a
note and I'll let you know what I know. you know?

    thanks and appreciation * alot

---
Aaron Pelton		    | If it sounds like an opinion, it's probably mine.
aaron@satco.UUCP            | Only R. Crusoe could have it all done by Friday
{decvax,uunet}!virgin!satco!aaron

Newsgroups: comp.databases.informix