HDTenEightyP/NetNews huggingface dataset:
From: mclemore@rebec.asd.contel.com (Ken McLemore)
Subject: Re: Interbase
Keywords: SQL
Reply-To: mclemore@rebec.asd.contel.com (Ken McLemore)
Organization: CONTEL Federal Systems
Distribution: USA
Date: Fri, 20 Nov 1992 13:41:22 GMT

we're currently using sybase but we'll be looking at interbase port
next week.  what feedback did you receive on interbase ?
thanks in advance, ken
From: webb@tsavo.hks.com (Peter Webb)
Newsgroups: comp.databases
Subject: Need info on DIF
Date: 23 Nov 1992 11:55:48 -0500
Organization: Hibbitt, Karlsson & Sorenson, Inc.
NNTP-Posting-Host: tsavo.hks.com

I'm looking for technical information on the DIF file format.  DIF stands for
Data Interchange Format (I think) and is a canonical format which many
different applications support.  For example, both VisiCalc and AmiPro can
read and write DIF files.  I want to write an application that reads and 
writes DIF files, but I don't know the file format.  I have several questions:

	1. Is there a document (either on the Net or published in a journal or
	   book) that describes the format?

	2. Who came up with the format (some consortium)?  Who controls any
	   modifications that might be proposed?

	3. Does the standard have "official" recognition, or is it a defacto
	   industry standard?

	4. How widespread is the use of DIF?

Any other information you might have on DIF would also be appreciated.  Thanks
very much.


-- 
Peter Webb 					webb@hks.com
Hibbitt, Karlsson & Sorenson, Inc.		Voice: 401-727-4200
1080 Main St, Pawtucket RI 02860		FAX: 401-727-4208
From: rhaven@cruzio.santa-cruz.ca.us
Newsgroups: comp.databases
Subject: Re: Does the -space option work for any Paradox users?
Summary: Paradox and the -space argument
Date: Fri, 20 Nov 92 19:57:24 PST
Reply-To: rhaven@cruzio.santa-cruz.ca.us




It sounds like you are starting your script from the command line when you
(or your batch file) starts Paradox.  This is fine, but the -space arguement
won't display until after that script has ended.  If you want to see the 
startup memory allocation, make sure you are starting Paradox "raw",
without any other arguments except for "-space".

The current feeling is about -codepool 750 for a 4 mb machine, maybe a little
more.  You will be trading query, report, and sort speed for increased PAL
performance (although things will _still_ be faster).

I hope this helps
From: briand@anasaz (Brian Douglass)
Newsgroups: comp.databases
Subject: Re: How About COMP.DATABASES.PARADOX ?
Date: 17 Nov 92 21:32:22 GMT
Organization: Anasazi, Inc.  Phoenix, Az

In article <1992Nov16.082944.7362@pony.Ingres.COM> jonm@Ingres.COM (DON'T JUDGE A BOOK BY YOUR COVER) writes:
>I have two opinions over this.
>
>	1)	I don't read the paradox questions anyway. So I could care
>		less if they were all placed in some dark cupboard.
>
>	2)	The Paradox question readers also contribute (Well) to the
>		general Q/A issues and their experience should be
>		valued.  Why No cope with the questions and then
>		just not read them if you feel they are cluttering space.

How about a comp.databases.dos?  

I could care less about questions on Paradox, Foxbase, Dbase, Clarion, etc, 
but clearly there needs to be a forum to addresse specific questions on these 
and other DOS products.  At least with a comp.databases.dos, we don't get 
cluttered with too many sub groups, comp.databases goes back to addressing 
generalized DBMS questions and people don't have read through things they 
don't care about, just to get to those items they do.

>
>________________________.
>Jon Machtynger	        |   All opinions expressed above are mine or
>jonm@ingres.com	        |   borrowed... do you understand that!  You can
>________________________|   just leave the company out of this!
>


-- 
"The best government of all is that government which governs the least."
	Jefferson
Brian Douglass		briand@anasazi.com 	602-870-3330 X657
Newsgroups: comp.databases,comp.org.sug,comp.sources.wanted,comp.sys.sun.apps,comp.sys.sun.wanted
From: pavlov@niktow.canisius.edu (Greg Pavlov)
Newsgroups: comp.databases,comp.databases.oracle,comp.databases.ingres
Subject: Re: I heard a Rumor about Oracle 7 and Forms
Date: 16 Nov 92 19:22:57 GMT
Followup-To: comp.databases,comp.databases.oracle,comp.databases.ingres
Organization: Canisius College, Buffalo NY. 14208

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.
> 
 I wouldn't worry about this too much.  ORACLE uses product release dates as
 a marketing tool:  don't buy Brand x because we have a New Improved coming
 out that will run circles around it.  As far as I am aware, ORACLE has never
 come close to meeting an ADVERTISED release date  - tho it may be meeting
 internally-set deadlines, I don't know - and is usually very creative in
 the many reasons given (directly and via "rumor") why the release is "delayed"

  greg pavlov
  pavlov@fstrf.org
Newsgroups: comp.databases
From: sethg@dcatlas.dot.gov (Seth Grimes)
Subject: InterBase Experiences?
Organization: U.S Dept. of Transportation
Distribution: comp
Date: Mon, 16 Nov 1992 21:32:27 GMT

I'd be interested in hearing about any positive or negative experiences 
people have had with InterBase from Borland.

It looks like a strong DB engine and a good solution for some work I
will soon be involved in, although it also looks like it has weak
applications development and non-TCP/IP networking.  On the other hand,
there are 3rd-party products for that would make up for the weaknesses.

Thanks,

Seth Grimes, dcatlas!sethg@uunet.uu.net


Newsgroups: comp.databases
From: rjmartin@extro.ucc.su.OZ.AU (Trilogy Business Systems)
Subject: Disk Configuration & Sybase
Summary: Question about the best configuration of mass storage for Sybase
Keywords: Disk Sybase
Organization: Sydney University Computing Service, Sydney, NSW, Australia
Date: Tue, 24 Nov 1992 00:04:44 GMT

I am currently making reccomendations for machine configurations for Sybase
SQL server. According to theory, it is far better to have a number of smaller
disks than it is to use one large disk e.g. 4 * 250 Mb drive on 2 different
controllers with disk 1 for the operating system, and log device, disk 2 for
all non clustered indexes, and disk 3 & 4 (on the second controller) used for
data, instead of 1 1.2 Gb disk.

At the moment my primary concern is performance (I am already convinced about
the benefits from a reliability viewpoint).

According to theory the more drive heads you distribute the data across the 
better your performace, however the 250 Mb drives I was looking at only had 4
heads (multiplied by four disks for a total of 16 heads) compared to the 1Gb 
drive's 14 heads. On top of this the data transfer rates, average seek times 
etc on the 1Gb drive were much better than the seek times etc for the 250Mb
drive. As Sybase was written when disk drives were much smaller, does the
"distribute across more drives = better perormance" theory still hold ?

The second question I have concerns RAID, and it's disk striping. I have heard
that this feature is great if you are grabbing large sequential chunks of data, however for random reads and writes (which is exactly the sort of thing we are
doing), the improvment is not as noticeable.

The third question I have has to do with disk caching mechanisms. Given that
Sybase looks after it's own data cache, and uses asynchronous disk I/O, is
there a significant advantage to having caching on the disk controller(s).

I would appreciate any feedback at all

Many thanks in advance

John Martin
Newsgroups: comp.databases
Date: Tue, 17 Nov 92 15:23:25 EST
From: Zhe Li <li@cs.columbia.edu>
Subject: Aloha, Hashing!


I wonder how many commercial RDBMS products really implement hashing to
process joins. If so, what kind of hashing functions are typically used?
Simple K mod Max? Random picking digits as the hash key? Or more complicated
ones? Any good ORDER-PRESERVING hash functions been used also to deal with 
inequality joins?

Cheers for the responses!

--lee

pls email to :

li@cs.columbia.edu
Newsgroups: comp.databases
From: ummalik@ccu.umanitoba.ca (Ijaz Rashid Malik)
Subject: Re: PARADOX HELP NEEDED re: auto fill of key field.
Organization: University of Manitoba, Winnipeg, Canada
Date: Fri, 20 Nov 1992 12:39:09 GMT


One quick and dirty way would be to copy it. Application  programmer
comes with a complete video store sample application. In that they
are using auto-increment of customer field when ever adding a new customer
to store's list. The source script itself is in c:\pd0x40\video and is
named vid-pal.sc.  Have a look at it and you will find very easy to 
customize it. And to see how they used it, start app. work shop from
Paradox system menu, change dir to pdox40\video and open video
application for editing.

Malik
Newsgroups: comp.databases
From: dtodd@titan.ucc.umass.edu (David M. Todd)
Subject: Re: AREV MULTIVALUE Symbolics
Keywords: AREV MULTIVALUE SYMBOLIC
Organization: University of Massachusetts, Amherst
Date: Tue, 24 Nov 1992 01:26:14 GMT

In article <cpetersn.722472899@vincent2.iastate.edu> cpetersn@iastate.edu (Clifton R Peterson) writes:
>No, It should be MD02.  You are right that the last digit is the scale which
>is the power of 10 to divide the data by before displaying it.  I did some
>testing just after putting this message up and got the following
>
>msg(oconv(123456,"MD02"))       => 1235
>msg(oconv(123449,"MD02"))	=> 1234
>
>At least, if I remember right, the problem was displaying DOLLARS type
>data rounded up to the nearest dollar or using MD0 without having to do
>the non-rounding divide of the data first.

My apologies--you were right.  Thanks for the clarification.


|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: jonm@Ingres.COM (DON'T JUDGE A BOOK BY YOUR COVER)
Subject: Re: How About COMP.DATABASES.PARADOX ?
Summary: 
News-Software: VAX/VMS VNEWS 1.4-b1  
Keywords: 
Organization: ASK Computer Systems, Ingres Product Division
Date: 16 Nov 92 08:29:44 GMT

I have two opinions over this.

	1)	I don't read the paradox questions anyway. So I could care
		less if they were all placed in some dark cupboard.

	2)	The Paradox question readers also contribute (Well) to the
		general Q/A issues and their experience should be
		valued.  Why No cope with the questions and then
		just not read them if you feel they are cluttering space.

________________________.
Jon Machtynger	        |   All opinions expressed above are mine or
jonm@ingres.com	        |   borrowed... do you understand that!  You can
________________________|   just leave the company out of this!

Newsgroups: comp.databases
From: dtodd@titan.ucc.umass.edu (David M. Todd)
Subject: Re: AREV MULTIVALUE Symbolics
Keywords: AREV MULTIVALUE SYMBOLIC
Organization: University of Massachusetts, Amherst
Date: Sat, 21 Nov 1992 12:53:55 GMT

In article <By038z.4qA@resntl.bhp.com.au> kevinb@resntl.bhp.com.au writes:
>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

I'm at home without access to AREV, but I think I can give you *A*
solution, though perhaps not an elegant solution.  Your last symbolic
is on the right track, but is trying to divide a multivalued field by
a number.  I'm pretty sure this will work

AMT = {AMOUNT}; VALUES = ''
CNT = COUNT(AMT)+NOT(AMT='')
FOR X = 1 TO CNT
   VALUE = AMT<1,X>/100
   IF X > 1 THEN VALUES := @VM
   VALUES := VALUE
NEXT X
@ANS = VALUES

Haven't tried it, but I wonder if you generate a multivalued
denominator, if your last format would work, i.e.

DENOM = 100:@VM:100:@VM:100
@ANS = {AMOUNT}///DENOM

I think that takes about as much programming though!

We should be able to write a function for this, passing two
parameters:

AMOUNTS = {AMOUNT}
PLACES = 2
@ANS = ROUND(AMOUNTS,PLACES)

FUNCTION ROUND
CNT = COUNT(AMOUNTS)+NOT(AMOUNTS='')
CONVERSION = 'MD':PLACES
DENOM = OCONV(CONVERSION,1)  ;/*Not sure this works, but there must be
                               some simple way to generate the
                               denominator from the number of places */
FOR X = 1 TO CNT
   VALUE = AMOUNTS<1,X>/DENOM
   IF X > 1 THEN VALUES := @VM
   VALUES := VALUE
NEXT X
@ANS = VALUES

>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. 

Agreed!  This is a lot of work for a simple function.  If there is an
easier way (and there should be) I haven't discovered it.  Don't know
why I haven't tried to create a function before and why I've never
seen one!


>handling of multivalues in dictionary items is a constant cause for concern.

True, but at least we *have* them!


|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: rgams@magnus.acs.ohio-state.edu (Richard A Gams)
Subject: Re: Getting Started in Paradox
Organization: The Ohio State University
       The BORDB forum is now known as PDOXDOX.  This forum is an absolute 
Date: Wed, 18 Nov 1992 17:01:27 GMT

-- Dick
Newsgroups: comp.databases
Subject: Bug with FOXPRO 2 SQL ???
From: david@datamark.co.nz (David Rowland)
Date: Mon, 23 Nov 1992 01:35:06 GMT
Organization: Datamark International Ltd.

Is it me or is there a bug with the FOXPRO 2 SQL language.

The bug is as follows:

If I had three tables

1:   KEYA   KEYB   2:  KEYA    3:  KEYB

     AAAA   1111       AAAA        1111
     BBBB   2222       BBBB        2222
     CCCC   3333       CCCC        3333

and I access them through the following statement

select *
from   table1, table2, table3
where  table1.keya = table2.keya
  and  table1.keyb = table3.keyb

I get the following

keya   keyb   table2.keya   table3.keyb
AAAA   1111      AAAA          1111
AAAA   1111      AAAA          2222
AAAA   1111      AAAA          3333
AAAA   1111      BBBB          1111
AAAA   1111      BBBB          2222
AAAA   1111      BBBB          3333
...

CCCC   3333      CCCC          1111
CCCC   3333      CCCC          2222
CCCC   3333      CCCC          3333

where I think I should have got 

keya   keyb   table2.keya   table3.keyb
AAAA   1111      AAAA          1111
BBBB   2222      BBBB          2222
CCCC   3333      CCCC          3333


Is this a bug and has it been fixed or should I be using the SET SKIP
TO commands and not bother with SQL for this type of relation.

Thanx.
-- 
| 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.dcom.isdn
From: bobh1@cbnewse.cb.att.com (Bob Haddleton)
Subject: Re: PacBell ISDN?
Reply-To: bobh@nwsca.ATT.COM (Bob Haddleton)
Organization: AT&T Network Systems, Lisle IL, USA
Distribution: usa
Date: Thu, 19 Nov 1992 18:10:31 GMT

In article <james.722191743@menaik> james@cs.UAlberta.CA (James Borynec; AGT Researcher) writes:
>kph@cisco.com (Kevin Paul Herbert) writes:
>
>>I am served by an ISDN-capable 5E switch, but am served remotely (I
>>live in the mountains and a 5E switch serves the entire valley that I
>>live in). PacBell offers ISDN for the wire center in which the switch
>>is physically located, but not in any of the remote wire centers.  
>>
>>My account executive speculates that this may be because they'd have
>>to devote an entire channel bank to ISDN lines, and they wouldn't want
>>to devote this much of their bandwidth unless I got 8 BRI lines. All I
>>want is 2...   
>
>>Does anybody know if this is the correct reason, or if there really
>>is a technical reason that they can't put ISLUs in the remote wire
>>center?  
>
>Some remotes cannot support ISDN line cards.  Thus they can't offer
>ISDN services from those remotes.  PacBell may not want to forklift
>upgrade those remotes.
>
>j.b.

The 5ESS can support ISDN in Remote locations, the problem is that the
ISLU (ISDN Line Unit) supports a minimum of 512 ISDN Lines.  (They
don't all have to be equipped, but the minimum hardware configuration
supports 512).  Add to that the fact that you must also have a more
powerful processor for the Remote's module controller and a Packet
Switch Unit to handle the Q.921/Q.931/X.25 traffic, and it adds up to
one VERY expensive proposition when you only have customers for 2 (or
even 8) lines.

If you can convince enough other people or businesses served off of
your remote to buy the service, you could probably talk PacBell into it
(money has a very loud voice).

-- 
Bob Haddleton		AT&T Network Systems    (708)224-6934
att!nwsca!bobh		Lisle, IL		bobh@nwsca.att.com

My opinions are my own, if I could only remember where I left them...
From: kph@cisco.com (Kevin Paul Herbert)
Newsgroups: comp.dcom.isdn
Subject: Re: PacBell ISDN?
Date: 17 Nov 1992 02:34:32 GMT
Organization: cisco Systems, Inc., Menlo Park, CA
Distribution: usa
NNTP-Posting-Host: cider.cisco.com

I am served by an ISDN-capable 5E switch, but am served remotely (I live in
the mountains and a 5E switch serves the entire valley that I live in). PacBell offers ISDN for the wire center in which the switch is physically located, but not in any of the remote wire centers.

My account executive speculates that this may be because they'd have to devote an entire channel bank to ISDN lines, and they wouldn't want to devote this much of their bandwidth unless I got 8 BRI lines. All I want is 2...

Does anybody know if this is the correct reason, or if there really is a technical reason that they can't put ISLUs in the remote wire center?

Kevin

P.S. For the person that asked about Oakland, CA - I'm pretty sure that
     there is only 1A ESS there, so you'd have to get Switched 56. There
     really are Pac*Bell folks that will let you know this. FYI, if you
     are in Oakland in wire center OKLDCA11, you are served by a 1AESS switch.
Newsgroups: comp.dcom.isdn
From: aaron@eng.umd.edu (Aaron Falk)
Subject: Re: Open market versus monopoly, was Re: Obtaining ISDN
Date: Wed, 18 Nov 92 20:19:47 GMT
Organization: College of Engineering, Maryversity von Uniland, College Park
Originator: aaron@ether.src.umd.edu


In article <1992Nov17.160614.10428@telebit.com>, bjork@telebit.com (Steven Bjork) writes:
>In article <1992Nov17.145659.5823@bmerh85.bnr.ca>,
> coghlan@bnr.ca (Patrick Coghlan) writes:
>
>>You need a NT1 and a terminal adapter or ISDN card for your PC.  You
>>can get both for around $1000 today.  I paid $3000 for an original IBM
>>PC with 16K memory and no disk drives in 1983.  I can get a 386 for
>>around $1000 today.  Would you care to guess what it will cost to have
>>ISDN in a few years?
>
>More than it costs today (no smiley).
>
>Your PC clone is the result of an *open market* and competition.
>

There is, however, competition in the TA market. I am a graduate student
working on the the S/W protocol for an IBM PC TA card for BRI access that
will sell for between $89 and $200 depending on whether you want D, B, or
2B +D, or all the above and CODEC capabilities. It probably won't be done
until next summer but the hardware exists.

With the CODEC your PC functions as your complete TA and becomes an ISDN
"phone".

So just stick around, the prices will come down eventually.

Aaron
-- 
_________________________________________________________
Aaron D. Falk        			aaron@src.umd.edu
phone (301) 405-6554
Room 2160 AV Williams Bldg. University of MD College Pk
Newsgroups: comp.dcom.isdn
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: X.25 ofer the D channel
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Sat, 21 Nov 1992 07:54:50 GMT

dunham@bonehead.esd.sgi.com (William Dunham) writes:
+---------------
| I understand that it is possible to run X.25 of the D channel of ISDN? 
| Anyone have any idea how popular this is? What are the applications for this?
+---------------

Obviously, it's not wide-spread yet (at least not in the USA), but there
have been several "well-suited" applications suggested:

1. Credit-card verification traffic. Instead of picking up a phone and
   dialing the credit-card verification center (as it does now), the
   little terminal would just send a D-channel packet.

2. All sorts of other POS traffic (e.g., debit cards).

3. Burglar alarms and other security functions. These would send "poll"
   messages to say that things were o.k., or not. (Silence would be taken
   as an indication that the line had been cut or the system tampered with.)

...and so on. Wherever the "call" is infrequent, the data small, yet the
needed round-trip time fairly low (lower than a call-setup time).

Note that for large amount of data, D-channel packet is going to be priced
*much* higher per bit than B-channel circuit data. But for the one-packet-
a-minute stuff...


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Newsgroups: comp.dcom.isdn
From: deej@cbnewsf.cb.att.com (david.g.lewis)
Subject: Re: bri lengths
Organization: AT&T
Date: Mon, 23 Nov 1992 14:13:15 GMT

In article <1992Nov22.055122.19365@nntpd.lkg.dec.com> goldstein@carafe.enet.dec.com (Fred R. Goldstein) writes:
>
>In article <1992Nov21.2070.618@channel1>, "chris strawser" <chris.strawser@channel1.com> writes...
>>I understand that the maximum distance an ISDN U-interface can
>>be run is 6 kilometers.  If this is so, how do you run a BRI
>>over longer distances?
>
>ISDN was designed for the worldwide market, where 18 kf (about 
>6 km) seemed adequate, as it picked up over 90% of loops.

Minor correction; the U-interface is a design twist unique to the US market
(although it can be adopted elsewhere, e.g. Canada, it's only specified in
American National Standards).  The "90% of loops with 18kfeet" is in the US,
and I would suspect in the RBOCs (since it was a pre-divestiture Bell Labs
study that suggested the number).

David G Lewis                              AT&T Bell Laboratories
david.g.lewis@att.com or !att!goofy!deej     Switching & ISDN Implementation
From: chiu@hacienda_hts.West.Sun.Com (Chiu Wen - SE Sun Encino - 818-905-0200)
Newsgroups: comp.dcom.isdn
Subject: ? GTE and ISDN
Date: 17 Nov 1992 21:31:56 GMT
Organization: Sun Micro. Inc., Los Angeles
Distribution: world
NNTP-Posting-Host: hacienda_hts.west.sun.com

Anyone care to comment on how to get ISDN service in Los Angeles?  GTE here seems
very unfamiliar with ISDN service.