HDTenEightyP/NetNews huggingface dataset:
From: black@sybase.com (Chris Black)
Newsgroups: comp.databases.sybase
Subject: Re: how poratble is embedded SQL across ORACLE, SYBASE, INGRES?
Date: 25 Jan 93 17:10:51 GMT
Organization: Sybase, Inc.

All of us at Sybase recognize the drawbacks with the 4.0 and pre-4.0
precompilers.  The new version coming out later this year is a 
complete re-write and should answer Gerald's concerns.

In article <1993Jan18.211146.15924@netcom.com> gtynen@netcom.com (Gerard Tynen) writes:
>I used Sybase's embedded SQL with COBOL on Unix last year.  My client was
>a great big bank in LA who was trying to downsize some DB2 applications.  
>Imagine our dismay when we discovered that the Sybase precompiler:
>
>	1) did not support COBOL packed decimal datatypes.  Packed decimal
>	is COBOL datatype normally used for money.  This was a bank.  They
>	had lots of packed decimal data in their programs.  Sybase expected
>	us to store all our money, therefore, in text datatypes.  AS-IF!

We will support comp-3 (packed decimal) as well as display (non-packed
decimal) in the next release.

>
>	2) In addition, if we wanted to map a COBOL variable into a Sybase
>	MONEY datatype, not only did we have to convert to text, but the
>	text field only allowed two places after the decimal.  We could not
>	read/write fractions of a cent through the precompiler, even though
>	the underlying Sybase datatype could have stored it.

The new decimal type support will take care of this.

>	3) We would have to do lots and lots and lots of rewriting of the
>	DB2 programs in order to use Sybase's precompiler. 

The new release will be NIST compliant, which will provide full
compatibility with other compliant databases.

>	4) Sybase support was not even aware that they had SQL precompilers
>	available.  We ended up having to talk to the engineers.  

This situation is improving, with in-house precompiler training for
our support staff.

We're all very excited about the new precompiler.  It's a vastly
improved product which should meet user needs in both C and COBOL.

-- Chris
black@sybase.com
From: mparsons@fleming.csc.bcm.tmc.edu (Mark Parsons)
Newsgroups: comp.databases.sybase
Subject: Re: Restricting access to rows?
Date: 28 Jan 1993 18:33:35 GMT
Organization: Baylor College of Medicine, Houston, Tx
Distribution: world
NNTP-Posting-Host: fleming.csc.bcm.tmc.edu
Originator: mparsons@fleming.csc.bcm.tmc.edu


In article <SPENCER.93Jan27153337@guraldi.med.umich.edu>, spencer@med.umich.edu (Spencer W. Thomas) writes:
> I want to restrict access to a table according to the value of a
> certain field, by user, according to a second "authorization" table.
> I.e.,
> 
> create table base (
> 	category	int,	/* The field to restrict access by. */
> 	data		int
> )
> 
> create table auth (
> 	uid		smallint,
> 	category	int
> )
> 
> uid	category
> ----	--------
> 2	1		User 2 can see categories 1&2
> 2	2
> 3	3		User 3 can only see category 3
> 4	1		User 4 can see categories 1,2&3
> 4	2
> 4	3

	. . . . ideas on view creation deleted . . . 

Maybe I'm missing something but . .. . . why do you need or want views?
Why not put the necessary code in your selects/updates/deletes? i.e.,
write the appropriate joins?

I've got several places in my application where I need to do this
very same thing, i.e., limiting selects based on values in another
table and the user's privileges.  I just write the joins into my
code.

You should be able to just use this as is in your code:

	select * from base where category in
		(select category from auth where uid=user_id())

Am I missing something?

Mark
Newsgroups: comp.databases.sybase
From: stuart@genethon.fr (Stuart Pook)
Subject: patindex broken between 4.2 and 4.8
Originator: stuart@genethon2.genethon.fr
Keywords: patindex
Organization: Genethon -- Human Genome Research Centre
Date: Thu, 28 Jan 1993 14:41:19 GMT


Has anybody noticed that patindex has been broken
between Sybase versions 4.2 and 4.8?  The following
scripts illustrate how patindex used to be correct
(under 4.2) and how it now gives the wrong result.

Does the same problem exist under 4.9?

$ sql -SGENGDB
1> select @@version
2> go
                                                                   
 ----------------------------------------------------------------- 
 SQL Server/4.2/P/sun4/os4/EBF632/OPT/Tue Aug 27 11:58:42 PDT 1991 

(1 row affected)
1> select patindex("%[^0]%", "000")
2> go
             
 ----------- 
           0 

(1 row affected)

$ sql -SGENETHON
1> select @@version
2> go
                                                                       
 --------------------------------------------------------------------- 
 SQL Server/4.8/P/Sun 4/SunOS 4.1.X/5/OPT/Fri Apr 24 10:15:10 PDT 1992 

(1 row affected)
1> select patindex("%[^0]%", "000")
2> go
             
 ----------- 
           3 

(1 row affected)
From: kevin@traffic.den.mmc.com (Kevin Rodgers)
Subject: Re: Sybase Support
Organization: Martin Marietta Western Internal Systems, Technical Operations
Date: Thu, 28 Jan 1993 17:52:53 GMT

In article <KKUJO_Z6X@linac.fnal.gov> kfreytag@mdtf14 (Kelley Trombly-Freytag) writes:
>Benjamin von Ullrich (ben@sybase.com) wrote:
>
>: i would expand to say that our engineers are already busy fixing hundreds of
>: bugs in our hundreds of products, ...
>:                   they're also responding to your requests for more features
>: and compatibilities, ...
>: and easier duplication of databases on multiple servers on the network.
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>Please! Is this some kind of enhancement being worked on now? What exactly
>is it and with what release will it be available!! I desperately need
>something like this.

It is called the Replication Server and is part of System 10, so it
should be available sometime in the second half of this year.  As I
understand it, it will provide fault-tolerant replication of tables (or
portions of tables) across servers via a message-queuing mechanism.
-- 
Kevin Rodgers				kevin@traffic.den.mmc.com
Martin Marietta MS A16401		(303) 790-3971
116 Inverness Dr. East
Englewood CO 80112 USA			GO BUFFS!
Newsgroups: comp.databases.sybase
Subject: Calling a 'C' Program from w/i a Stored Procedure
From: lundell@gumby.mgi.com
Date: 22 Jan 93 17:44:24 CST
Organization: Management Graphics, Inc.

Hi,

Is it feasible from within a SYBASE Stored Procedure to call an executable
program that was written in 'C'??

I understand that this might be doable using Sybase's Open Server Library.
If so, what is involved, how much of an effort (time-wise) for a seasoned
'C' programmer is required, and what would the cost be for this library
on an RS-6000????

Would using the Open Server Library provide for returning the result set to
the client on the network in the same manner as how stored procedures
currently work???

I also understand that one might be able to use Net-Lib and get down to the
socket level for transferring data (from a 'C' program run as an RPC) to the
client on the network. Is this possible??? If it is, what requires less
development time -- Net-Lib or Open Server???

Thanks. I know this is a fair number of questions. If I can help clarify any
of these -- please let me know!

-Jim
Newsgroups: comp.databases.sybase
From: wolfgang@fraser.sfu.ca (Wolfgang Richter)
Subject: Locking a table against update
Keywords: lock
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Thu, 21 Jan 1993 17:34:16 GMT

The following was e-mailed to me and is likely of interest to others.

Wolfgang,

I thought I would drop you a response to your posting regarding
explicitly locking tables in Sybase.  I have not been following
the news group until recently, so if this information seems new
to you, please feel free to post it:

To explicitly lock a table in Sybase, and avoid a deadlock problem:

   begin transaction

      update <table_name_here> 
      set    <some_column_name> = <some_value> 
      where  0 = 1
      
      /* Table is now exclusivly locked, perform atomic function */
   
   commit transaction
   

The trick here is the 'where 0 = 1'.  This will put a lock on the
table (until the commit transaction) without actually changing 
any data in the table (obviously 0 never equals 1).

Any other processes will block at the 'update' statement, and will
wait until the 'commit transaction' before proceeding.  No more
deadlocks!

Good luck!

Paul Tidwell, Software Engineer
Ericsson Network Systems
Richardson, Texas 

-- 
-- Wolfgang Richter (e-mail: wolfgang@sfu.ca)
-- Academic Computing Services
-- Simon Fraser University
-- Burnaby, B.C.
-- Canada V5A 1S6
-- Phone: 604-291-4449
From: Dave_Wetzel@vos.stratus.com (David Wetzel)
Newsgroups: comp.databases.sybase
Subject: Re: syslogs
Followup-To: comp.databases.sybase
Date: 25 Jan 1993 22:09:15 GMT
Organization: Stratus Computer
Distribution: world
NNTP-Posting-Host: dwetzel.mis.stratus.com

My Opinion:
I don't really expect Sybase to give us the format of the logs.  I
personally don't really want them.  I *DO* however want audit trail
functionality embedded in the DBMS.  That's one of the many tools that
we've come to expect from a DBMS that don't exist in Sybase.

If I understand the original request correctly, they're looking for the
format of syslogs because there is no internal audit trail feature.  That's
reasonable.

Thanks,
Dave_Wetzel@vos.stratus.com
From: kfreytag@mdtf14 (Kelley Trombly-Freytag)
Newsgroups: comp.databases.sybase
Subject: Re: Sybase Support
Date: 27 Jan 93 21:30:39 GMT
Organization: Fermilab, Batavia, IL
X-Newsreader: TIN [version 1.1 PL8]

Benjamin von Ullrich (ben@sybase.com) wrote:

: i would expand to say that our engineers are already busy fixing hundreds of
: bugs in our hundreds of products, ...
:                   they're also responding to your requests for more features
: and compatibilities, ...
: and easier duplication of databases on multiple servers on the network.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Please! Is this some kind of enhancement being worked on now? What exactly
is it and with what release will it be available!! I desperately need
something like this.

--
Kelley Trombly-Freytag
Newsgroups: comp.databases.sybase
From: jbaron@higgs.ssc.gov (Jeff Baron)
Subject: Re: syslogs
Reply-To: jbaron@higgs.ssc.gov (Jeff Baron)
Organization: Superconducting Super Collider Lab
Date: Fri, 22 Jan 1993 19:23:34 GMT

Lee McGee writes:

- Why this command is not available to users is a _mystery_ to me.
- It is extraordinarily useful for analysis of the update behavior of 
- application SQL - (what?  inserting 10 rows causes HOW MUCH physical 
- IO? WHY?) - somehing that every Sybase database administrator in 
- the land ought to have access to. 

and 

- This group ought to demand to Sybase that "dbcc log", and any other 
- benign technique that might by highly useful to the user community, 
- be published for general use.  It does not matter whether Sybase 
- log formats are confidential or not, and frankly the log format 
- should be of no concern to the user.  What does matter is that we 
- are able to report on log contents, for problem analysis.

Oh sure.  Do we think that the log is a valuable part of the Sybase
product?  Do we think that Sybase itself has some vested interest in
protecting its product?  Do *other* companies give out data structure
definitions (and source code?) for their products?  Do you think that
if you *demand* something that it will happen, regardless of the 
unreasonableness of the request?

The log serves two purposes.  To recover from software failures, such
as an OS crash, and to recover from hardware, or disk, failures.

How do you expect it to provide you with information about performance 
analysis in the case of your 10-update example?  Do you think that the 
log contains information about the physical disk i/o involved in this
command, such as the time spent waiting, or the other pages that were
*read* while doing the update?  I don't think so.

--
Jeff Baron
jbaron@gauss.ssc.gov
Newsgroups: comp.databases.sybase
Subject: Problem when calling an RPC from a Stored Procedure
From: lundell@gumby.mgi.com
Date: 22 Jan 93 17:26:16 CST
Organization: Management Graphics, Inc.

Hi,

We currently have our Sybase Server running on AIX on an RS 6000. I have 
written a Stored Procedure that makes an RPC call via Open Server to an 
IBM mainframe that has SUPRA.

I am able to get my result sets back just fine when everything is working OK.
However, I have noticed the following anomaly. If the RPC fails due to the
user not having an acitve account on the IBM mainframe it appears to return
-4 (permission error) as expected when I am in ISQL. However, control is not
returned to my Stored Procedure; but rather it appears to abort when the Stored
Procedure fails. This unfortunately results in a -1 being returned to the 
clients on the network.

We would like to be able to display a meaningful error message to our users
of our system. Is there away for me to capture this error code (-4) returned
from a RPC or to gain control again when I am in the stored procedure?? Are you
able to read in the SQL Communications Area from a stored procedure??

Thanks in advance!!

-Jim
From: college@vivaldi.EBay.Sun.COM (Darrell Choy)
Newsgroups: comp.databases.sybase
Subject: Query Optimizer for 4.8
Date: 25 Jan 1993 16:37:03 GMT
Organization: Sun Microsystems, Inc.
Distribution: world
Reply-To: college@vivaldi.EBay.Sun.COM
NNTP-Posting-Host: vivaldi.ebay.sun.com

I'd like to know how does the Sybase query optimizer work.  Does the ordering of
the tables in the from clause or the conditionals in the where clauses affect
the performance of the query?

Thanks,

Darrell



Newsgroups: comp.databases.sybase
From: rob@fosters.med.utah.edu (Rob Sargent)
Subject: Re: WordPerfect -> Sybase
Organization: University of Utah
Date: 27 Jan 93 23:57:24

>  Our plan is:
>			      C program 	  DB lib.
>	WordPerfect 5.1 file -----------> ASCII -----------> SYBTEXT in database
<	
<  Our WordPerfect files only contain text (plain, bold faced, underlined, italic

1. "bold face, underlined, italic" is NOT plain text. I seriously
doubt that the escape sequences involved will be of any value
displayed inside an APT window.

2. I think that you would be better off using a system call to either: 
	a:invoke WordPerfect on the file ( if you have (unixWP)
	b:run more on mantained ascii versions of the files (in lieu
	of placing them in the database)
--
Rob Sargent                      s-mail: Dept. of Human Genetics    
e-mail: rob@fosters.med.utah.edu         U. of Utah Medical School     
				         Eccles Genetics Bldg
				         Salt Lake City, Utah  84112

Newsgroups: comp.databases.sybase
From: caw@gtech.com (Christopher A. White)
Subject: Stored Procedures and temp tables
Keywords: lock
Organization: GTECH Corporation, West Greenwich, RI
Date: Thu, 21 Jan 1993 18:20:32 GMT

[ I don't know if any of you have had a hard time figuring out
how to do this, but we did for some reason, so I figured I post
a copy of my internal note. If you didn't already know this,
it can save you a lot of code and make things easier.]

Here is a little programming tidbit: #temp tables created in a
stored procedure are visible to stored procedures call by the
creator. So, if procedure a creates #techs and then calls 
procedure b, b can use, access, update, etc. #techs.

The problem we've always had is that the called procedure (b,
in this example) could not be created. However, I have come
up with a way to do so. It requires adding some code to the
procedure creation script [our scripts have a section at the top
that drops the procedure if it already exists, then the creation
script itself. Since they are isql scripts, each section is
terminated with a "go"].

Since we know what proc b exepects to be in the temp table,
we can put the temp table creation clauses in the section
between the drop procedure and the create procedure, like this:

If exists (select * from sysobjects ... etc
   drop procedure b
go

select * into #techs from techs where 1 = 2
go

create table #display as (disp_line   char(80) )
go

create procedure b as
.
.
.
go

The #temp tables must be the SAME in both procedures (a and b).


Topher
-- 
 Christopher A. White                    | Free Radical Programming
 caw@gtech.com                           |   High combat Rock'n'Roll 
 GTech Corporation, West Greenwich, RI   |      Software - Break the rules
 The opinions expressed are mine alone   |         and take no prisoners!
From: jja@fnbc.com (Joseph Alotta)
Newsgroups: comp.databases.sybase
Subject: Re: Sybase Support
Keywords: support
Date: 27 Jan 93 15:18:51 GMT
Organization: First National Bank Of Chicago, Chicago IL, USA


well i'm very glad that the sybase employees like each other.

perhaps they know what it like to have production problem and their
only line of help is an refusenick operator and some unnamed engineering
staff that never gets back to you.

i support the customer who wrote in.  i've had the same problems, so
has ever other person here.  and everyone else i know who uses sybase.  

i still am waiting on tech support with an answer to my problems, a
week and 3 days now.  (i installed 4.9.1 and performance is crap.)

spend more time getting the problems fixed and less time telling
us how excellent you all are.


joe.


--
==============================================================
! joe alotta                                    jja@fnbc.com !                                               
!                                             (312) 732-3439 !
!                                                            !
! "The main thing is to keep the main thing the main thing." !
! Dr. George Sweeney                                         !
==============================================================
Newsgroups: comp.databases.sybase
From: nigelc@cognos.com (Nigel Campbell)
Subject: Sybase/SVR4
Organization: Cognos Incorporated, Ottawa CANADA
Date: Wed, 27 Jan 1993 23:16:56 GMT

Which SVR4 based Unix boxes is Sybase certified and which
if any share the same release tape vs a tape specific to
a derivative of SVR4. thanks.

-- 
Nigel Campbell          Voice: (613) 738-1338 ext 3016    P.O. Box 9707
Cognos Incorporated       FAX: (613) 738-0002             3755 Riverside Dr.
Database and Connectivity MCI: nigel campbell || 307-4729 Ottawa, Ontario
UUnet: nigelc@cognos.COM                                  CANADA  K1G 3Z4
Newsgroups: comp.databases.sybase,comp.sys.novell
From: daborton@va (David A. Borton)
Subject: Re: Sybase NLM: TCP/IP or IPX/SPX?
Organization: Novell, Inc.
X-Newsreader: Tin 1.1 PL4
Date: Tue, 26 Jan 1993 02:38:06 GMT

paul@eunet.co.at (Paul Gillingwater) writes:
: 
: We've decided to go for LWP for DOS, to connect our PC's running Windows
: on a Novell network with TR adaptors, to a UNIX box with an Ethernet
: adaptor.  Am I right in assuming that Novell's MPR 2.0 will support
: routing for this scenario?

Yes, paul, the MPR can route IPX or IP traffic from a TR network to an
Ethernet network.

: 
: Another key question, which may be related to TCP/IP support for Sybase
: clients -- I consider TCP/IP to be inherently insecure, unless run with
: e.g. Kerberos. Question: will Kerberos work with LWP, and is anyone
: using this in a client/server environment with Sybase?
: -- 
: Paul Gillingwater
: Home system: paul@actrix.co.at (Waffle)

I do not know of Kerberos can be used here, but I do know that Sybase clients
can access the database server using just IP, no problem.
-------
Here am I sitting in a tin can...
Newsgroups: comp.databases.sybase
From: wfinnert@larry.shearson.com (Warren Finnerty)
Subject: Re: Stored Procedures and temp tables
Organization: Lehman Brothers
Date: Fri, 22 Jan 1993 14:28:00 GMT

In article <1993Jan21.182032.23975@gtech.com> caw@gtech.com (Christopher A. White) writes:

>   [ I don't know if any of you have had a hard time figuring out
>   how to do this, but we did for some reason, so I figured I post
>   a copy of my internal note. If you didn't already know this,
>   it can save you a lot of code and make things easier.]
>
>   Here is a little programming tidbit: #temp tables created in a
>   stored procedure are visible to stored procedures call by the
>   creator. So, if procedure a creates #techs and then calls 
>   procedure b, b can use, access, update, etc. #techs.
>
>   The problem we've always had is that the called procedure (b,
>   in this example) could not be created. However, I have come
>   up with a way to do so. It requires adding some code to the
>   procedure creation script [our scripts have a section at the top
>   that drops the procedure if it already exists, then the creation
>   script itself. Since they are isql scripts, each section is
>   terminated with a "go"].
>
>   Since we know what proc b exepects to be in the temp table,
>   we can put the temp table creation clauses in the section
>   between the drop procedure and the create procedure, like this:
>
>   If exists (select * from sysobjects ... etc
>      drop procedure b
>   go
>
>   select * into #techs from techs where 1 = 2
>   go
>
>   create table #display as (disp_line   char(80) )
>   go
>
>   create procedure b as
>   .
>   .
>   .
>   go
>
>   The #temp tables must be the SAME in both procedures (a and b).

CAUTION:

I use this technique for some items that really *have* to be done
this way, however....

There have been cases where if a index that a child proc uses is dropped
the proc refuses ( is unable ) to recompile itself and gives a nasty
message until reloaded ( 4.0.1 EBF726 )

>   Topher
>   -- 
>    Christopher A. White                    | Free Radical Programming
>    caw@gtech.com                           |   High combat Rock'n'Roll 
>    GTech Corporation, West Greenwich, RI   |      Software - Break the rules
>    The opinions expressed are mine alone   |         and take no prisoners!
--
warren finnerty      | 388 Greenwich St.
Lehman Brothers      | NYC NY 10013
"Back off man!"      | wfinnert@shearson.com
From: brent@spss.com (Brent Lambert)
Newsgroups: comp.databases.sybase
Subject: Re: how poratble is embedded SQL across ORACLE, SYBASE, INGRES?
Date: 21 Jan 93 18:09:08 GMT
Organization: SPSS, Inc. - portable code group

In article <1993Jan11.171828.20794@sni.ca>, chandra@xenon.nabu.sni.ca (Chandra Sekar) writes:
> I am presently specifying some APIs for an application, designed to run
> on multiple databases.
> 
> Many of the APIs involve SQL DMA underneath.  I think if I use embedded SQL
> and at generate time, use the vendor specific pre-compilers (ex: ORACLE Pro*C)
> it can be ported across DBMSs easily. 
> 
> But then there are these many 'middleware' products and many vendors like JYACC, 
> GUPTA, OMNIS and others offer 'database independent' layered products.
> 
> Which way should I go?

I recently went through this for a commercial application I was working on.
It turned out to be quite a pain, and probably was not worth the cost of
development.  Unfortunately, someone simply decided that we should write our
own API, and there was no investigation of existing API's.  Given a chance
to do it over again, I would recommend seriously investigating middleware.

In your case, however, you need to evaluate your application requirements.  Is
it for internal or external use?  Can you require your users to install and
maintain the middleware?  Can you afford the cost of using the middleware
(royalties, etc.)?  Can you afford to update and re-release your API every
time Sybase or Oracle ships an update (weekly)?  How much functionality,
flexibility, and robustness do you need from your API (or the middleware)?

One thing is for sure:  If you try to write Embedded SQL that is portable
among DBMS vendors, you'll end up in preprocessor Hell.  And probably deserve
to be there.


-- 
The above statements are not the opinions or policies of SPSS Inc.
The above statements may not be the opinions of Brent Lambert.
The first disclaimer is a policy of SPSS Inc.
Subsequent disclaimers are probably the opinion of Brent Lambert.
Newsgroups: comp.databases.sybase