HDTenEightyP/NetNews huggingface dataset:
From: bohannon@pepper.rutgers.edu (Philip Bohannon)
Newsgroups: comp.databases
Subject: Re: Paradox for Windows. When???
Date: 12 Dec 92 02:53:23 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

... stuff deleted ...

> 
> >I am wondering if we will see a WORKING Paradox for Windows someday.
> 
> Paradox for Windows will be released way ahead of dBASE for Windows
> if that makes you feel better about Borland's intentions.
> 
> Dan Veditz
> daniel@borland.com
> Int'l R&D (dBASE)

Speaking of which, I got the impression a while back that Paradox for
Windows would not be able to share files on a network with Paradox 4.
I hope this is impression gets corrected (rather than confirmed) ...?
(It would seem embarrassing if Approach is a smoother upgrade path
from P4 than P for Windows.)

On the original topic, I agree that the missing features clearly
belong in the system, not in PAL.  Had they been there, this would
have been a Killer upgrade, rather than just good.  

The new features in P4, while useful, are not at all convenient
(though several hateful things in 3.5 WERE made much more convenient).
In fact, we seem to have mostly gotten wrappers for the Turbo Vision
C++ library...

Ironically, the "paradox" referred to in the name was that the
database was so powerful, yet so easy to use.  Now the old tradeoff is
back: you can have a good app, just program and program and...

In Borland's defense, they are simultaneously at work on 5 database
products that I can count (Pdox, Pdox Win, dB, dB Win, Interbase), as
well as trying to form some coherent strategy out of the mess. I'm
rooting for them. 

Still looking for that utopian development environment,

Philip Bohannon			(bohannon@paul.rutgers.edu)
Newsgroups: comp.databases
From: james@library.nrl.navy.mil (James King)
Subject: Re: MICROSOFT ACCESS vs FOXPRO
Organization: NRL
Date: Fri, 18 Dec 1992 12:57:13 GMT

In article <1992Dec12.004240.23761@netcom.com> messina@netcom.com (Tony Porczyk) writes:
>From: messina@netcom.com (Tony Porczyk)
>Subject: Re: MICROSOFT ACCESS vs FOXPRO
>Date: Sat, 12 Dec 1992 00:42:40 GMT
>jcberger@grasp1.univ-lyon1.fr (Jean-Claude Berger) writes:
>
>>Does anybody knows what will be the Microsoft policy about
>>Access vs. FoxPro (for Win). Is Access an end user product and Fox a
>>developper oriented one ? Are they aimed at the same market ?
>
>I purchased Access solely based on the information from Miscrosoft that
>they will have a distribution kit for it some time early next year, end
>of January, early February.
>
>t.

One of the big differences between FoxPro and Access is that FoxPro uses the 
XBase language for programming and Access uses TrueBASIC.  I would say 
the other big difference is that FoxPro is cross-platform and has the 
Rushmore query engine, whereas Access does not, yet.

R. James King
Naval Research Lab
Microsoft Support Coordinator
From: meh@atlantis.Unify.Com (Mark E. Hansen)
Newsgroups: comp.databases
Subject: Re: Interative SQL Query Question
Date: 15 Dec 92 20:26:28 GMT
Organization: Unify Corporation, Sacramento, CA, USA

In article <1992Dec5.195857.1775@uunet!cbmvax!xmws!kripalu>, harit@kripalu.com writes:
|> In article <lhv4hlINN9ne@jethro.Corp.Sun.COM> pmccurdy@alcalde.Corp.Sun.COM  
|> (Patrick McCurdy) writes:
|> > 
|> > Hi All,
|> > 
|> >    I have been struggling with this one for quite some time, and I
|> > just can't seem to get it right.
|> > 
|> >    My table has a column called requestor.  Now, it is a simple
|> > matter to find out how many of the rows were requested by any
|> > specific requestor with:
|> > 
|> > 
|> > 	select count(*)
|> > 	from TableName
|> > 	where Requestor = 'name'
|> > 
|> > 
|> >    But what if I want to select the count for EACH distinct
|> > requestor?   I have tried:
|> > 
|> > 
|> > 	declare @REQ varchar(25)
|> > 	while (select @REQ = (distinct(Requestor)))
|> > 	begin
|> > 		select count(*) 
|> > 		from HRISPerm
|> > 		where Requestor = @REQ
|> > 	end
|> > 
|> > 
|> > but this does not work.  Any help on this question would be greatly
|> > appreciated.
|> > 
|> > 
|> > Patrick McCurdy
|> > Systems Support Specialist
|> > Sun Micro
|> 
|> try something like this:
|> 
|> select count(*) from HRISPerm group by Requestor

I'm sure you meant:
    
    select count(*), Requestor from HRISPerm group by Requestor

The count by itself wouldn't be very useful.


|> 
|> 
|> -- 
|> Michael Allen Latta
|> Kripalu Center
|> harit@kripalu.com
|> (413)448-3288

-- 
Mark E. Hansen                                     internet: meh@Unify.Com
Unify Corporation                           ...!{csusac,pyramid}!unify!meh
3901 Lennane Drive                                   voice: (916) 928-6234
Sacramento, CA 95834-1922                              fax: (916) 928-6401

          ** If there is no solution, there is no problem **
Newsgroups: comp.databases
From: srlncnc@gopher.dosli.govt.nz (Chris Crook)
Subject: FoxPro problem with outer join
Organization: Department of Survey and Land Information, New Zealand
Date: Mon, 21 Dec 1992 01:26:36 GMT


Can anyone offer any advice on how to solve the following problem in FoxPro
(other than by using Paradox!).

I have a one table (table1) with the following fields

    unique_key
    field1
    field2

and a second table (table2) with the fields

    unique_key
    field2

The key is common to the two tables, but table2 has only a subset of the
key values that are present in table1.  I would like to do is replace the
field2 values in table1 for which there is a corresponding key in table2,
leaving the rest of table1 untouched.

I cannot do an SQL join because I would lose most of table1 (ie the records
for which a key does not exist in table2).  I would prefer to avoid using
a SCAN on table2, because it could be SLOW!

Have you any suggestions - is there anything obvious I have missed in the
bulky manuals?

Thanks in advance for any suggestions.


Chris Crook
From: Bruce.Feist@f615.n109.z1.fidonet.org (Bruce Feist)
Sender: Uucp@blkcat.UUCP
Newsgroups: comp.databases
Subject: Logical design experiences?
Date: Wed, 16 Dec 1992 07:21:26 -0500

Hi, Mark;

 g> Please tell me of any positive or negative experiences you
 g> have had with developing databases with or without quality logical
 g> designs.  Any stories would be more than welcome.  If you know of any
 g> studies along these lines, please let me know.  Thank you very much.

Ah, the tales I can tell...  I can think of three offhand.  Here goes...

Story the First:

Organizational units could have any *one* of three possible types of code
associated with them.  There are overlapping values between the codes (for
instance, 'X' might be valid for both a type 1 code and a type 2 code).  Users
tend not to think about there being separate types codes, though.

In an old design, there were *four* code fields: a generic one, plus one for
each of the three types (only the correct one was to be filled out).  Which one
was filled out indicated the type of code; the 'generic' one was there, I
believe to simplify indexing.

I was asked to help in a redesign.  I pointed out that the current design was a
structure; what if a berserk program filled out *two* of the type-specific
fields, or none at all?  It would be better to store a single code value, along
with an indicator specifying what type of code was being stored.  The original
designer explained that in practice that would never happen.

I then looked at the data.  It had *already* happened.  My proposed change went
through.

Story the Second:

Same system.  Organizational units can have two addresses -- a home address and
and a current one (they move around).  This suggested to me that other addresses
might be useful in the future -- possibly an address for a standard training
site, for instance.  I proposed normalizing the location information out into
another table.  The original designer explained that there was no way that more
than these two locations would ever be required.  The project manager called in
a user later during the meeting; he mentioned in passing that they were thinking
about storing a third type of location.

Story the Third:

Different portion of the same system; this happened in the personnel portion.
Normalization resulted in many (call it 20) tables to describe personnel.  For
'efficiency', the original designer (same fellow as above) decided to include a
status flag in each of them; the idea was that this would speed up selection. In
practice, it has turned out that queries almost invariably specify a single
master table (possibly joined with others), which is where the status flag
really belongs.  So, there is minimal speedup in queries -- but their update
program, which must frequently update the status flag, takes 12 hours or so to
run -- roughly 20 times longer than necessary.  As far as I know, the status
flags are in synch from table to table -- but I wouldn't bet on it.

Bruce
From: mayer@andromeda.rutgers.edu (Warren Mayer)
Newsgroups: comp.databases
Subject: Comparison of Paradox 4.0 and Paradox/Windows
Summary: I would like a comparison/contrast between Paradox 4.0 and Paradox/Win
Keywords: Paradox 4.0, Windows
Date: 15 Dec 92 21:47:40 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

I need your opinions on the differences between Paradox 4.0 and Paradox for 
Windows (as yet unshipped). Can any of the Borland folk shed some light on
this for me (without violating the non-disclosure agreements that are out
there?).

I need to show my supervisor that differences matter between the two and that
purchasing a copy of the Windows variety for Windows 3.1 vs. creating access
through Windows for the DOS version is the wise thing to do.
(Personally I've liked Paradox since version 3.5 and strongly suggest that
he purchase the two versions for the appropriate environments) but then again
I don't have "the power to purchase", he does.

Warren Mayer
Rutgers University - Newark, N.J.
mayer@andromeda.rutgers.edu
From: jcberger@grasp1.univ-lyon1.fr (Jean-Claude Berger)
Newsgroups: comp.databases
Subject: Re: MICROSOFT ACCESS vs FOXPRO
Date: 11 Dec 1992 23:10:37 +0100
Organization: INSA Informatique, Lyon, France
NNTP-Posting-Host: grasp1.univ-lyon1.fr

In article <1992Dec10.124112.1@skcla.monsanto.com> jjfink@skcla.monsanto.com writes:
>Anyway, I spoke with some Microsoft folks at the Database Expo in Chicago
>yesterday (it's still going on today (Thursday)).  FoxPro 2.5 for Win and Dos
>are starting to ship, and unix/Mac are expected sometime in '93.
>
>Access will not be available for Mac for quite some time, nor will Visual
>Basic, because both VB and AccessBasic were coded in Intel assembler :(
>

Does anybody knows what will be the Microsoft policy about
Access vs. FoxPro (for Win). Is Access an end user product and Fox a
developper oriented one ? Are they aimed at the same market ?


 ----------------------------------------------------------------------------
 Jean-Claude Berger, JCBerger Developpement Formation (Free Lance Consultant)
 (+33) 78.24.75.78     E-Mail : jcberger@grasp1.univ-lyon1.fr - BIX, jcberger
From: RROXBY@MAINE.MAINE.EDU (Robert Roxby)
Newsgroups: comp.databases
Subject: Paradox SE vs Full 4.0?
Date: 13 Dec 92 18:52:46 GMT
Organization: University of Maine System

What does the SE version of Paradox omit?  Thank you.  Robert
Newsgroups: comp.databases
From: csc4213@gsusgi2.gsu.edu (Uncle Remus)
Subject: Re: Foxpro 2.0 on a network 
Organization: Georgia State University
Date: Sun, 13 Dec 1992 03:55:04 GMT

viking@iastate.edu (Dan Sorenson) writes:

>	I have no idea what 2.5 is going to be like.  Somebody mentioned a
>"six pack" network version.  If I have to pay extra for more than six users,
>I'm sticking to version 2.0 -- I refuse to limit my software licenses.

The "Six-pack" version is referring to use of the actual foxpro environment. 
Distributed exe's have unlimited network usage. BTW, this has been the only
way to get foxpro 2.0 lan since a little while before micosoft bought out fox.


Josh Guttman
InterMed Software



-- 

Uncle_Remus - 404-355-0001   "Yeah, I've heard of Internet" - GSU User Services
       "I tried safe sex once, but I couldn't remember the combination" - Me
  "If you're gonna rock the boat, make sure you know who owns the ship" - Me
csc4213@gsusgi2.gsu.edu, Uncle_Remus, The Remulater, Josh, Guttman, Anton_Levey
Newsgroups: comp.databases
From: landers@comm.mgmt.purdue.edu (Chris Landers)
Subject: Re: Clipper...Set Unique On/Off
Date: Thu, 17 Dec 1992 14:03:44 GMT
Organization: Krannert Graduate School of Management, Purdue University

In article <18587@mindlink.bc.ca> John_Carson@mindlink.bc.ca (John Carson) writes:
>
>It has come to my attention on a client program that SET UNIQUE ON/OFF can be
>the start of corrupted index files. 

Yes, this can cause problems if you're not aware of it.....

>I assume that if you SET UNIQUE once with
>the database you must all the time. If at some location in the .PRG'S it
>isn't....trouble begins. 

Your assumption is wrong.
Any index created or reindexed with SET UNIQUE ON will be a UNIQUE index, 
that is, only the first occurance of the key will be included in the index 
making the database appear as if it has no duplicate records.

Once an index has been created UNIQUE, it is always UNIQUE, regardless of
the status of SET UNIQUE.  My advice is to SET UNIQUE ON just before 
creating or reindexing an index you want UNIQUE, then set it OFF immediately 
after.

>Has anyone else had this problem?
>
>What pseudo code do you suggest do to solve duplicate records without using
>this SET UNIQUE ON/OFF.
>

Sorry, I don't have any handy.

    <================================><=================================>
    ||  Christopher Landers          ||  Purdue University - KRAN 708  ||
    ||  Krannert Computing Center    ||  West Lafayette, IN  47907     ||
    <=================== landers@comm.mgmt.purdue.edu ==================>
From: merv@gpstwr.UUCP (Merv Graham)
Newsgroups: comp.databases
Subject: Serial data type - Which systems have it?
Keywords: serial datatype database relational
Date: 15 Dec 92 20:13:40 GMT
Distribution: comp
Organization: Graham-Patten Sys., Inc., Grass Valley, CA

I'm in the unfortunate position of having to  give up my Informix SQL on
a UNIX box.  I inquired about moving the license to my new box, but,
IMHO, informix wanted way too much money for a single person, personal
machine copy.

My new machine runs both Dell UNIX and DOS/Windows and I have serveral
RDBM to look at. (FoxPro, Paradox and now Access).

My problem:   One of the features that I rely on in Informix is the
"serial" data type. (ie. the system assigns a unique serial number as a
column (field) for each row (tuple, record [take your pick] added).
Of the systems whose manuals I've been able to peruse, only Access seems
to have this feature (they call it "counter").  I have a copy of FoxPro
that I haven't even loaded yet, because it doesn't seem to support the
serial data type.

My  Question:
Do any of the systems I mentioned have this type of data type (or
function) available and I just haven't found it in TFM. And second,
are there any other reasonably priced systems that support it.

Second problem:  outer joins, but that's the subject of another post.
-- 
Merv Graham                 |     gpstwr!merv@gvgpsa.gvg.tek.com
Graham-Patten Systems, Inc. | or: tektronix!gvgpsa.gvg.tek.com!gpstwr!merv
P.O. Box 1960               | 
Grass Valley, CA 95945      | Ph: 916-273-8412   FAX: 916-273-7458
Newsgroups: comp.databases
From: cpetersn@iastate.edu (Clifton R Peterson)
Subject: Re: Advanced Revelation information request
Organization: Iowa State University, Ames IA
Date: Thu, 17 Dec 1992 18:41:39 GMT

In <1gqe5aINNt3n@crcnis1.unl.edu> price@helios.unl.edu (Chad  Price) writes:

>A minor semantic point, but important if you are looking for a rules enforcer!

And, if you really need an application where the users must use the dictionary,
it is definitely possible to not let them use the editor and force the only
data accesses to be through the entry window, or the reporting functions,
thus using the dictionary rules.  If they need to use the editor for some
tasks, then it would still be possible to put in an MFS that checked all
writes to be sure they were from the desired places only.

(Note: MFS - Modified Filing System.  It is possible to put programs that
any call to the Base Filing System must go through that can do many tasks
that are related to the data structure and not the application, per se.
One such thing is a READ-ONLY MFS that only passes on read-type calls, none
of the write-type calls get passed down to the data level.)

Clif
-- 
 _________________________________________________________________________
/ Clifton R. Peterson    1108 Burnett		(515)232-5254	    	  \
| B.S. Chem E            Ames IA  50010                                   |
\_______________"42"_is_one_hell_of_an_answer!!___________________________/
From: holowcza@andromeda.rutgers.edu (Richard D Holowczak)
Newsgroups: comp.databases
Subject: Re: References wanted on Distributed Databases
Date: 18 Dec 92 03:49:56 GMT
Organization: Rutgers Univ., New Brunswick, N.J.


dmmatt@bigez (Mike Mattix) writes:

>In article <Dec.15.16.02.57.1992.27495@andromeda.rutgers.edu>, holowcza@andromeda.rutgers.edu (Richard D Holowczak) writes:
>> 
>>   I think there is a big difference between distributed partitioned data and
>> distributed replicated data.  I would be interested to know how Rdb (and
>> others) handle site failures, communication failures and recovery.
>> Any comments?
>> 
>> 
>> 
>> Rich Holowczak
>> Rutgers University
>> holowcza@andromeda.rutgers.edu

>  Since I brought up Rdb (I just get sick of hearing about the NEW ADVANCED
>features of Oracle/Ingres), I probably should take a stab at this.  The 
>application we did originally had distributed partitioned data (multiple 
>table of different data on different network nodes).  The application 
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

O.K.  This can be (and is being) done by many vendors. As to who did it
first, I have no idea.   The problem with performance you state is 
remedied by replicating data.  The goal (via, say one-copy token approach)
is to dynamically move the data close to the people who need it while
still allowing access from all others who might.  This is a tricky bit
of business which I don't think Rdb or others is up to. 

The new Sybase release is supposed to handle this although not very
gracefully from a theoretcal standpoint.


>worked fine we ended
>up consolidating the application on one node for performance reasons.  I don't 
>believe many people will argue that distributed applications tend to 
>perform worse
>than applications where all the data resides on one node.

   See above. 

>The failure of a node is 
>handled by the two phase commit function during a transaction.  
>The failure of a node 
>is handled by error trapping after that, ie the application will not be able to 
>regards,

>-- 
>Mike Mattix
>Agricultural Group of Monsanto
>P.O. Box 174
>Luling, LA 70070
>INTERNET Address: dmmatt@bigez.monsanto.com

---
[1mRich Holowczak[m               holowcza@andromeda.rutgers.edu
Rutgers University
Ph.D. Computers and Information Systems Program
"Availability of Distributed Databases During Network Partitioning"
+---------------------------------------------------+---------------+
| The .sig, the whole .sig and nothing but the .sig | Ask about the |
|           <<< This space for rent >>>             | car alarm FAQ |
+---------------------------------------------------+---------------+
From: bq035@cleveland.Freenet.Edu (Brian Jepson)
Newsgroups: comp.databases
Subject: Re: Foxpro 2.0 on a network
Date: 12 Dec 1992 23:13:01 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: bq035@cleveland.Freenet.Edu (Brian Jepson)
NNTP-Posting-Host: hela.ins.cwru.edu


In a previous article, viking@iastate.edu (Dan Sorenson) says:
>
>	I have no idea what 2.5 is going to be like.  Somebody mentioned a
>"six pack" network version.  If I have to pay extra for more than six users,
>I'm sticking to version 2.0 -- I refuse to limit my software licenses.

   They are currently selling 2.0 in six-packs. However, when I called for my
free upgrade disks to the most recently patched version of 2.0, they said that
our unlimited license is good, but that I was to install one copy of the 
executable for every six users, or some such nonsense. I hope that when we 2.0
users upgrade, that we will get this same treatment, although it sounds a bit
kludgy.

   To reply to the originator of this thread, no, the claim that Foxpro needs
a dedicated server is a twisted lie, probably concocted in the bowels of Fox's
competitors ;-).
-- 
*  __                _____                        Brian Jepson
* /__)  __ . __ __     /  __   _   /  _   __      iqm229@uriacc.uri.edu
*/___) /  / (_// / (__/  (_/  /_) _) (_) / /      bq035@freenet.cwru.edu
*                         `- /
Newsgroups: comp.databases,comp.databases.ingres,comp.databases.oracle
From: sethg@dcatlas.dot.gov (Seth Grimes)
Subject: DB work on Unisys/MCP mainframes?
Organization: U.S Dept. of Transportation
Distribution: comp
Date: Fri, 18 Dec 1992 15:49:24 GMT

Anybody out there doing DB work with commercial relational DBMSes on A
Unisys mainframe running MCP?  If so, what about with clients residing
elsewhere?

Thanks,

Seth Grimes, grimes@oecd.fr
Newsgroups: comp.databases
From: dat92bro@ludat.lth.se (Bjarne Rosengren)
Subject: Primabase, any one?
Keywords: Primabase windows
Organization: Dept of Computer Science, Lund University, Sweden
Date: Wed, 16 Dec 1992 10:41:14 GMT

I would like to get some info about a database program under windows.
It's name is Primabase. I have read an article in PC-mag and like to know
if any one have seen it and tested it them selves?

/Bjarne Rosengren
(dat92bro(at)ludat.lth.se)

Xref: sparky comp.databases:8460 comp.databases.oracle:2495
From: strobel@newton.mcs.gvsu.edu (Stephen Strobel)
Newsgroups: comp.databases,comp.databases.oracle
Subject: Re: Weird ORACLE update statement
Date: 12 Dec 92 14:32:57 GMT
Distribution: na
Organization: Grand Valley State University, Allendale MI

In article <1992Dec8.210428.22025@cbnewsk.cb.att.com> jrmo@prpix2.att.com (J.R.Moore) writes:
>In article <1992Dec8.153620.9115@infonode.ingr.com> mcintyre@infonode.ingr.com (John Scott Mcintyre) writes:
>>	I am using ORACLE and want to be able to update rows in table1 using
>>	columns from table2 when the two tables can be joined.
>>
>>	The SQL statement I would like to perform would look like this:
>>
>>	update table1 set table1.manufacturer=table2.manufact,
>>		      set table1.pur_cost=table2.sale_cost
>>		where table1.inv_number=table2.inv_number;
>>
>>	The problem is UPDATE apparently cannot handle multiple tables.
>>
>Try this:
>
>UPDATE table1 A
>SET 	manufacturer=(
>		SELECT table2.manufact
>		FROM table2
>		WHERE A.inv_number=table2.inv_number
>		),
>	pur_cost=(
>		SELECT table2.sale_cost
>		FROM table2
>		WHERE A.inv_number=table2.inv_number
>		)
>WHERE	inv_number IN (
>		SELECT table2.inv_number
>		FROM table1,table2
>		WHERE table1.inv_number=table2.inv_number
>		)
>;
>
>Joe Moore

Better yet:

Update Table1 A
Set (manufacturer, pur_cost) =
    (Select manufacturer, sale_cost
     from   table2 B
     where  A.inv_number = B.inv_number)
-- 
|--------------------------------------|--------------------------------------|
|  Stephen Strobel                     | Phone: (h) (616) 235-1263            |
|  Grand Valley State University       |        (w) (616) 940-4241            | |                                      |  Mail: strobel@newton.mcs.gvsu.edu   |
|--------------------------------------|--------------------------------------|