HDTenEightyP/NetNews huggingface dataset:
From: kevinb@resntl.bhp.com.au (Kevin Black)
Subject: AREV MULTIVALUE Symbolics
Keywords: AREV MULTIVALUE SYMBOLIC
Reply-To: kevinb@resntl.bhp.com.au
Organization: BHP Research - Newcastle Laboratories
Date: Fri, 20 Nov 1992 05:58:11 GMT

I have a simple requirement that has wasted a deal of time.  An invoice
file holds a multivalued field for invoice amount.  This field is defined 
as MD2,$ ie.  formatted to $1,234.56.  What I want is a symbolic to round 
up the decimal places as MD0,$.  Apart from lots of gacky equations the following
has been tried with raw data of 123456~1234 (result denotes the amount and
amount.rnd fields):

	formula 				result
						amount		amount.rnd

	@ans = {amount}				$1,234.56	$123,456
						   $12.34	  $1,234
	@ans = {amount}/100			non-numeric when numeric expected

	@ans = {amount} /// 100			$1,234.56	$1,235
						   $12.34	    $0
	
T my mind this should be one of the trivial exercises.  After numerous other 
and much more complicated attempts I'm back to square one.  Note that on the first 
multivalue when it works it actually rounds correctly without any code.  The
handling of multivalues in dictionary items is a constant cause for concern.
Any help appreciated.  					 

Thanks,
Kevin
-------------------------------------------------------------------/\/\---
Kevin Black     Computer Systems Group Leader                     / / /\
                BHP Research - Newcastle Laboratories, Australia / / /  \
Snail   :       P.O. Box 188, Wallsend 2287                     / / / /\ \
Tel     :       +61 49 510434 Fax: +61 49 513740                \ \/ / / /
Internet:       kevinb@resntl.bhp.com.au                         \  / / / 
------------------------------------------------------------------\/\/\/--
From: joet@dcatlas.dot.gov (Joe Trott)
Subject: Re: MANY-TO-MANY mess in Paradox!!!
Organization: U.S Dept. of Transportation
Date: Fri, 20 Nov 1992 21:30:45 GMT

ummalik@ccu.umanitoba.ca (Ijaz Rashid Malik) writes:

[stuff deleted]
>say, from an input screen I am entering info about new products or new
>suppliers. If its products, it can have a variable number of vendors and
>if it is a vendor, there could be a variable # of products for it. How can
>I design an input screen/form that has linked tables on it and handeles
>multiple entries for a given field. I mean I can use Products as master
>form and use vendors as linked embeded form. Now when ever I enter a new
>product, I am not sure how many vendors for this product there will be.
>Could be 0,1, or 10000!!! How can I design an input screen and then table
>which would handle this situation????

You might use three tables; 1) Product Master, 2) Vendor Master, and 3) Links.
Reports and forms would use the third table as the Master table.  It would
have only two fields, like Product Number and Vendor Number, which would be
primary keys in their respective tables.  You would have to enter all the
products and all the vendors before linking them.  In the LINKS table, you
would use TableLookups to make sure the Product and Vendor numbers were
valid; depending on how comfortable you are with PAL, you could have the
system accept new products and/or vendors if a particular code were entered.
You could also use the Product and Vendor tables to create input forms, if you
use a different imbedded form from LINKS for each one.  Reports though, would
almost certainly be driven from LINKS, which could pull data from either
Master table.

I'm sure that was as clear as mud, so if you're left with more questions, I'll
try to do a better job of answering.

-JTT
From: rhaven@cruzio.santa-cruz.ca.us
Newsgroups: comp.databases
Subject: Re: PARADOX HELP NEEDED re: auto fill of key field.
Summary: AutoIncriment fields in Paradox
Date: Sat, 14 Nov 92 19:52:57 PST
Reply-To: rhaven@cruzio.santa-cruz.ca.us



There are several ways to impliment autoincriment fields in Paradox, all
of which involve PAL programming.  They fall in to two broad catagories:
keeping a seperate table with the last id used and incrimenting it; and
finding the "highest" value in the table itself and incriment that.

In a multi-user situation, things get more complicated because each user
need to make sure that when they try to use the "next" key, another user
isn't trying to do the exact same thing.  But it's not that hard to do.

As a general note, I use alphanumeric fields for ID rather than numeric fields
because they are easier to manipulate.  Even if a key value is numeric, it
has no intrinsic numeric value; it is merely a range of possible values.
Therefor, I usually start my id sequence at 100000 for A6 fields, 1000000
for A7 fields, etc.  Starting with all digits used avoids any leading
zero confusion.

Technique 1:  Keep the last number used in a seperate table.  This table can
either be imbedded into the master form as an unlinked form with the
attributes of black on black so it is invisible, or positioned off the
desktop (Paradox 4.0 Standard interface).  In either case, you use PAL
to detect when the user enters a new record (the function RecordStatus("New")
is good for that).  You can either check after certain keys (3.5 style) or
trap on the ARRIVEROW event (4.0 style).  When the new record is detected,
move to that table (WINDOE SELECT in 4.0) and lock the single record there.
If you get the lock, that means no onle else is trying to add a record; if not,
wait a few seconds and try again.  Then incriment the value in the single 
field in that table and post the record.  YOu now have a key value that you
know no other session will try to use,  Move back to the main data form and
insert the key value into the key field,

Technique 2: calculate the key from the table itself.  You could try to use
CMAX() or ImageCMax() to get the highest value (on a numeric field), but
that requires a WL, and if any other session has a record lock, the WL
will fail.  A better approach is to move to the end of the table (which is in
key sequence), get the value, incriment it to get a new value, add the new record
(which will become the new "last" record), and use it.  TO avoid the multi-
user danger described above, you need to set a signal (or semaphore) to
warn others away for as long as it takes to add the new record.  You can do
this by using the LOCK command.  You can LOCK a non-existant table.  If you
use a LOCK "Adding" FL, it will fail if anyone else is LOCKing the same
imaginary table.

Anothe way is a rather dangerous technique using SETBATCH (available only in 4.0)
Ask me if you are really interested.

I hope this helps

RCH
From: field@cs.pitt.edu (Brian Field)
Newsgroups: comp.databases
Subject: Paradox 4.0 and ASCII delimted files
Date: 20 Nov 92 17:17:59 GMT
Organization: Univ. of Pittsburgh Computer Science


I've recently started moving ASCII delimited files into Paradox 4.0.  I have
many different files that I need to get into Paradox.  Now the Import/ASCII
Delimited option works great except that the field names are "Field-1", 
"Field-2", ...etc.,  Is there a way to get Paradox to interpret the first
row in the ASCII file to be the field name?  Even better if I could specify
it's type as well.  

Other alternatives welcome. I would prefer *not* to define the tables in
Paradox in advance, and then append, since some of the tables field
number/types may still change.

Please e-mail.  I'll summarize.

Thanks,
Brian
-----
field@cs.pitt.edu
Newsgroups: comp.databases
From: david@datamark.co.nz (David Rowland)
Subject: Re: Character supression/FoxPro 2.0
Date: Tue, 17 Nov 1992 20:41:05 GMT
Organization: Datamark International Ltd.

In article <4f28_im00VQj48ZPJU@andrew.cmu.edu> Brandon Chin <bj+@CMU.EDU> writes:
>I'm using FoxPro 2.0 and I'm implementing a login screen.  The user
>enters a userid and a password.  How do I supress the keyboard echo or
>substitute it with a different character?  I need to do this so the
>user's password doesn't echo onto the screen.  I can't figure out how to
>do this in FoxPro 2.0.
>

@ x, y GET M.password COLOR N/N, N/N, N/N, N/N
-- 
| David Rowland       | The British are using New Zealanders.  They must |
| Datamark Intl Ltd   | really mean business !                           |
| Wellington          |      -  General Rommel During Northern African   |
| NEW ZEALAND         |         Campaign WWII.                           |
Newsgroups: comp.databases
From: sss@world.std.com (Sergiu S Simmel)
Subject: When a Database Won't Do! [Talk Announcement]
Organization: Penobscot Development Corporation, Arlington MA
Distribution: usa
Date: Tue, 17 Nov 1992 16:07:09 GMT


		      The Greater Boston Chapters of the
		     ACM, IEEE Computer Society and SIGMOD
				   present:

		       Kala(tm) -- When a DBMS Won't Do!

			       Sergiu S. Simmel
		       Penobscot Development Corporation
				 Arlington MA

			   Thursday 10 December 1992
		     7:00 PM with refreshments at 6:30 PM
			 Newman Auditorium, BBN, Inc.
			       70 Fawcett Street
				 Cambridge, MA


     Where do you keep your persistent data?  We've had two main options so
far: file systems (FSs) and database management systems (DBMSs).  For many of
us, neither choice is good enough.

     On one hand, FSs are often unreliable, provide no data consistency, few
offer versioning, sharing is primitive at best, and you have to keep
transforming data between "internal" and "external" forms all the time.  But
they are fast, they can hold any data, they are easy to use, and -- the price
is right!

     On the other hand, true DBMSs support sharing and data integrity,
transactions and versioning (although the specifics may not be exactly what
your application needs), are scalable, and tend to be more robust.  But they
are slower by an order of magnitude or more, they confine you to the kind of
data they happen to know about (or you may impose any structure on a BLOB --
back to where you were with files, only much slower), they are hard to use,
quite complicated, and -- expensive in money, system resources, and operational
costs!

     Not a bright picture in the economics of quality! Is there a happy medium?
Something with the speed and flexibility of files, the reliability,
shareability and robustness of databases, and a cost that won't break your
wallet or the available hardware?  Sure there is!  A new class of products, the
Persistent Data Servers, point to that direction.

     We will introduce Kala, the first commercial persistent data server.  This
brief presentation will cover the basics of the Kala model, as well as an
application example.

Biography

     Sergiu S. Simmel is co-founder and President of Penobscot Development
Corporation, a company specializing in persistent data management technologies,
software, and services.  Over the past eleven years, he has worked for several
software companies as an engineer and manager in the areas of CASE,
object-based technologies, persistence and language semantics.  He has been
with the Kala Project for over six years.  Mr. Simmel received a MS in Computer
and Information Sciences from the University of Minnesota.  He is currently
working on a book on the Kala technology for Addison-Wesley.


Newsgroups: comp.databases
From: ummalik@ccu.umanitoba.ca (Ijaz Rashid Malik)
Subject: How About COMP.DATABASES.PARADOX ?
Organization: University of Manitoba, Winnipeg, Canada
Date: Sun, 15 Nov 1992 15:25:39 GMT


Hello,
comp.databses is quickly becoming comp.databases.paradox. But I know there
still are many user [as I once was] who dont know where to direct there
paradox related articles on UseNet. I would really like to see Paradox have
its separate and dedicated forum. I guess Paradox has earned this level of
recognition.

If we agree on this, then either we can go thru the newsgroup creation
process [takes atleast 2 months] or we can start with alt.databases.paradox.
[in later case, I can help].

What do you think--is it worth it?

Malik
ummalik@ccu.umanitoba.ca
Newsgroups: comp.databases
From: drkhoe@nmt.edu (ONID)
Subject: Survey - Research
Organization: New Mexico Tech
Date: Thu, 19 Nov 1992 03:04:16 GMT

                              QUESTIONNAIRE
                         TO EXAMINE CAFFEINE USE
                        AMONG COMPUTER SCIENTISTS
                         AND ELECTRICAL ENGINEERS
                                     
Most of us enjoy consuming caffeine in one form or another. The purpose of
this questionnaire is to examine how much caffeine is being consumed, what
form the caffeine is being consumed in, and who is consuming it.

Please answer these questions with email to: bob@jupiter.nmt.edu
with the subject 'survey'.

**Please do not post your answers, that will waste bandwidth**

You don't have to quote the whole article, just use 6 lines or so:
EXAMPLE
	1 CS
	2 85 cans
	3 Jolt
	4 5 pots
	5 none (gives me a headache)
	6 45 Vivarin/hr.

Thank you!

1. What is your field of work/study?
    EE       CS        BothNeither

2. How much soda do you consume per day (average)?
    ________

3. What kind of soda do you drink?
    ________

4. How much coffee do you consume per day (average)?
    ________

5. How much tea?
    ________

6. Do you take any caffeinated pills? If so, how many?
    Vivarin  NoDoze    Maximum Strength Excedrin
    ______   ______    ______

bob@jupiter.nmt.edu
Bob "Chunkstyle" Broilo
-- 
----------------------------------------------------------------------------
Amiga to the Bone | SF2 Fanatics: Can you hang with the Guile combo's?
Moshing - the number one dance in America.  Kill the preacher hang the pope.
-------------------------------drkhoe@nmt.edu-------------------------------
Newsgroups: comp.databases
From: copler@moose.cs.indiana.edu (judith copler)
Subject: WORKSHOP ON CURRENT & FUTURE TRENDS IN DATABASE TECHNOLOGY
Organization: Computer Science, Indiana University
Date: Thu, 19 Nov 1992 14:39:33 EST
X-Mailer: Mail User's Shell (7.2.3 5/22/91)


WORKSHOP TITLE:

CURRENT AND FUTURE TRENDS IN DATABASE TECHNOLOGY

Friday, Dec 4, 1992 

INDIANAPOLIS, INDIANA

Objective:  All participants should gain an understanding of the
trends in database architectures, the trends in both general and
specialized database systems, and how the most popular of these
trends are being incorporated into commercial relational database
systems.

Who Should Attend:  Analysts, database applications programmers,
database designers and administrators, MIS managers, technology
consultants

Instructors:  Ed Robertson and Dirk Van Gucht

Session I -  Introduction:  How Trends Are Born 9:00-9:30
A.  Sources of Change
B.  The Change Time Line
C.  The Politics of Change

Session 2 - Trends in Information System Architecture 9:30-10:30

A.  Client/Server Database Architectures
B.  Distributed Database Architectures
C.  Parallel Database Architectures
D.  Heterogeneous Database Architectures
E.  Example:  A Parallel Distributed Decision Support System

Session 3 - Trends in Database Systems 10:45-12:15

A.  Expert Systems and Deductive Database Systems
B.  Object-Oriented Database Systems
C.  Heterogeneous Database Systems
D.  Extensible Database Systems
E.  Example:  An Expert System

Session 4 - Trends in Specialized Database Systems 1:15-2:15

A.  Text Databases
B.  Temporal Databases
C.  Large Object Database 
D.  Scientific Databases
E.  Example:  A Biomedical Database System

Session 5 - Trends in Commercial RDBMS Products 2:30-4:00

A.  Supporting Client/Server Architectures
B.  Supporting Distributed Architectures
C.  Supporting Constraints
D.  Supporting Object Identity
E.  Supporting Procedures and Triggers
F.  Supporting Various Types of Indexes and File Organizations
G.  Offering More and Better Tools

Session 6 - How Trends are Adopted 4:00-4:30

A.  Gaining a Competitive Advantage
B.  Evaluating Products
C.  Developing In-house Expertise
D.  Selecting a Methodology and Tools which Support It

For registration and other information please contact

Ms. Hallie Rose
812-855-2490
 
Newsgroups: comp.databases
From: maw@nch.NORASIA.COM (Mathew Wlodarczyk)
Subject: Sybase small(datetime) format
Keywords: Sybase, data type, datetime, format
Organization: Norasia Shipping Services SA, Fribourg, Switzerland
Date: Fri, 20 Nov 1992 10:52:41 GMT


Hi,

we are having problems with the small(datetime) data type in Sybase 4.8
on SUN. We would like to use the European format - dmy for input and output
(I guess the format in which dates are stored cannot be changed), and to
set this as default for all users of the SQL server. Is seams to me that
the easiest way to do it is by modifying

		dateformat=mdy
to
		dateformat=dmy

in the file ~sybase/locales/us_english/common.loc, as described on page
4-2 of the International Supplement to the System Administration Guide.
(I only have the 4.2 version of this manual, 4.8 probably does not exist
and 4.2 is valid for 4.8 too [??].) Unfortunately, this what the manual
says works for modifying names of months or their abbreviations, but it
does not work for the date format, at least for me. I also restarted
the SQL server and I even did a new installation, but it still does not
work.

Does anybody know whether it should work and how to do it? What is the
best alternative? SET DATEFORMAT works only for the current session and
does not work for the output format. I would not like to use CONVERT.

Thanks in advance.
Mathew.


----------------------------------------------------------------------------
Prediction is very difficult, especially of the future.		- Niels Bohr
----------------------------------------------------------------------------
Mathew Wlodarczyk					maw@nch.norasia.COM
Norasia Shipping Services		Fribourg		Switzerland
Newsgroups: comp.databases
From: wesleyl@borland.com (Wesley Leung)
Subject: Re: Mismatched dBase IV Memo fields
Originator: wesleyl@genghis.borland.com
Organization: Borland International
Date: Wed, 18 Nov 1992 22:54:07 GMT

>Has anybody experienced a problem with dBase IV that looks like
>the memo field for a record has been lost and another is in its
>place. It is like the Block Pointer Value is pointing to the 
>wrong Block in the .dbt file. 

>I have had this problem a couple of times in two different programs.
>I have reindexed and packed, not much else to do, the data in question
>to no avail.

>Is there a utility that is available that can fix this type of problem.

There is a utility that may help recover and fix some of your memo fields.
The utility is called DBTCHECK and is located on the Borland Download
Machine.  (408)439-9060 (8N1)  There are also other utilities there like
DBTCNVT and DBFCLEAN which will change your memo block size to save disk
space and the other will clean the .DBF of extraneous characters and
corrupted headers.  There are also corresponding unix executables incase
you are running the unix versions.

Wes,
-- 
Wes,
From: DVaz@cup.portal.com (David D Vazquez)
Newsgroups: comp.databases
Subject: Re: Normalizing 2NF -> 3NF
Date: Mon, 16 Nov 92 22:02:05 PST
Organization: The Portal System (TM)
  <1992Nov15.223825.16263@odin.diku.dk>
  <1992Nov16.103334.15543@neptune.inf.ethz.ch>
  <1992Nov16.135135.3108@odin.diku.dk>

marti@nugget.inf.ethz.ch (Robert Marti) writes:
.  :
.  FDs:  A -> B and B -> C
.  Relation: R(A*,B,C)
.  Problem: How to decompose?
.  Suggestion: R1(A*,B) and R2(B*,C) or R1(A*,B) and R2(A*,c)
.              ^^^^^^^^^^^^^^^^^^^^^
.Yes, but this might not be efficient. Fx, if there are two groups of users
.that wants to see an (A,B) and an (A,C) view resp., it requires a lot of
.unnecessary joins. Eg, (A,B,C) == (Name,Address,Phone#). You typically look up
.addresses from names and phone-numbers from names---not phone# from addresses.
.

It may make that specific query faster, but it can wind up costing you more
disk space.  While R1(A*,B) and R2(A*,C) are in 3NF given the above stated FDs,
you will have alot of redundant (repeated) data (3NF is supposed to solve this
correct?).

.A DBMS should be able to check other integrity constraints than primary keys. 

Correct, but a 'database design' should enforce all of the given functional 
dependencies (R1(A*,B) + R2(A*,C) will not).

.-- 
.         Niels Elgaard Larsen          
.         Institute of Computer Science,        
.         University of Copenhagen      
.         E-mail: elgaard@diku.dk 

  David Vazquez
  Computer Science major @ University of New Orleans
  E-mail: dvaz@cup.portal.com and dvazquez@sdiserv.cs.uno.edu
From: ehrlich@andromeda.rutgers.edu (Heyward Ehrlich)
Newsgroups: comp.databases
Subject: Paradox Increment Key Field
Date: 16 Nov 92 04:21:25 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

There are several ways of doing this that Borland suggests.
You can get help by calling their 800 number or by asking for
support via fax.

Heyward Ehrlich (ehrlich@andromeda.rutgers.edu)
Newsgroups: comp.databases
From: kmallory@oracle.com (Kevin Mallory)
Subject: Re: I heard a Rumor about Oracle 7 and Forms
Followup-To: comp.databases
Organization: Oracle Corp., Belmont CA
	<13NOV199213095729@erich.triumf.ca> <49670@shamash.cdc.com>
Date: Thu, 19 Nov 1992 17:15:07 GMT
X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.

In article <49670@shamash.cdc.com> jeff@svl.cdc.com (Jeff Needham) writes:

   Xref: oracle comp.databases:19448 comp.databases.oracle:2121 comp.databases.ingres:1801
Path: oracle!pyramid!gossip.pyramid.com!olivea!charnel!rat!usc!zaphod.mps.ohio-state.edu!darwin.sura.net!spool.mu.edu!umn.edu!noc.msc.net!uc.msc.edu!shamash!jeff
   From: jeff@svl.cdc.com (Jeff Needham)
   Newsgroups: comp.databases,comp.databases.oracle,comp.databases.ingres
   Date: 16 Nov 92 19:32:58 GMT
   References: <1992Nov13.184731.21707@cs.rochester.edu> <13NOV199213095729@erich.triumf.ca>
   Sender: usenet@shamash.cdc.com
   Followup-To: comp.databases
   Lines: 25

   grant@erich.triumf.ca (Peter A. Grant) writes:

   >In article <1992Nov13.184731.21707@cs.rochester.edu>, zhang@cs.rochester.edu (Zhang Ju) writes...
   >> 
   >>I heard a rumor which goes that the delay of ORACLE 7 is because of its
   >>incompatibility with Forms 3. So Oracle 7 is actually waiting for Forms 4.
   >>...

   >heard ORACLE7 supports SQL*Forms 2.3 and 3.0.  It's being released before

   Forms2.3 and 3.0 have PL/SQL V1 compilers running inside them, the kernel uses
   PL/SQL V2.  You can't single-task link Forms 3.0.16 to V7 kernels, otherwise
   no problem.

   But who uses single-task anyway ;-)


   later,me


   --
   Buy Nerve Net or go to jail!
   | Jeffrey Needham
   | Yet Another Oracle Performance Group
   | Control Data Systems Inc - Santa Clara, CA - jeff@hawk.svl.cdc.com
--
---------------
Kevin Mallory	Oracle Corporation - Redwood Shores, California
SQL*Forms Development
I don't speak for Oracle, nor they for me.
Remember: If you can find someplace you laik better 'n' Tuna... **MOVE**!
Newsgroups: comp.databases
From: aahz@netcom.com (Mean Green Dancing Machine)
Subject: Re: Paradox 4.0 and ASCII delimted files
Organization: Don't blame me, I voted for Bill 'n' Opus
Date: Fri, 20 Nov 1992 19:30:19 GMT

In article <9973@blue.cis.pitt.edu.UUCP> field@cs.pitt.edu (Brian Field) writes:
>
>I've recently started moving ASCII delimited files into Paradox 4.0.  I have
>many different files that I need to get into Paradox.  Now the Import/ASCII
>Delimited option works great except that the field names are "Field-1", 
>"Field-2", ...etc.,  Is there a way to get Paradox to interpret the first
>row in the ASCII file to be the field name?  Even better if I could specify
>it's type as well.  
>
>Other alternatives welcome. I would prefer *not* to define the tables in
>Paradox in advance, and then append, since some of the tables field
>number/types may still change.

Your best bet is to create *two* ASCII-delimited files, one with the
other data, and the other with the structure.  Write a PAL script to
import the structure file, create the appropriate table, the Import |
AppendDelimited the data file.
-- 
                         --- Aahz (the *other* Dan Bernstein)
                             @netcom.com 

Hugs and backrubs -- I break Rule 6

Trying to be happy is like trying to build a machine for which the only
specification is that it should run noiselessly.
Xref: sparky comp.databases:7968 comp.databases.ingres:1946