Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

Metadata stored procedures - is this temporary or long term?

2 posts in JDBC Connect (product renamed to JConnect) Last posting was on 1997-05-20 20:20:09.0Z
Edward Bauer Posted on 1997-05-06 13:45:58.0Z
Message-ID: <336F3616.4B54@stsci.edu>
Date: Tue, 06 May 1997 09:45:58 -0400
From: Edward Bauer <bauer@stsci.edu>
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5 sun4m)
MIME-Version: 1.0
CC: bauer@stsci.edu
Subject: Metadata stored procedures - is this temporary or long term?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Newsgroups: sybase.public.jdbcconnect
Lines: 22
Path: forums-1-dub!forums-master.sybase.com!forums.powersoft.com
Xref: forums-1-dub sybase.public.jdbcconnect:872
Article PK: 252624

I notice that you need to have stored procedures loaded on any Sybase
database inorder to get jConnect metadata classes to work.

Is this a long term solution to the JDBC metadata interfaces for
jConnect? This seems like an unnecessary implementation - couldn't this
be done by passing query strings at run-time? It also adds a
configuration burden to any Sybase database that you want to use
meta-data + JDBC + jConnect on?


If the answer about this being a long-term solution is yes, could you
explain why this approach was taken? Can you also verify that this is a
jdbc-compliant solution?


JDBC's meta-data are a great idea - I am concerned that the jConnect
implementation lessens the usefulness of these interfaces.


Thanks!

Ted


P.S. I hope my posting here is not a re-hash of old postings, I didn't
see any in this vein...


David Clegg Posted on 1997-05-20 20:20:09.0Z
Message-ID: <33820779.7E43AEA2@sybase.com>
Date: Tue, 20 May 1997 13:20:09 -0700
From: David Clegg <davec@sybase.com>
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.2.13 i586)
MIME-Version: 1.0
To: Edward Bauer <bauer@stsci.edu>
Subject: Re: Metadata stored procedures - is this temporary or long term?
References: <336F3616.4B54@stsci.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Newsgroups: sybase.public.jdbcconnect
Lines: 41
Path: forums-1-dub!forums-master.sybase.com!forums.powersoft.com
Xref: forums-1-dub sybase.public.jdbcconnect:811
Article PK: 252563

This IS our long-term design. The problem with hardcoding queries
to pass in at run-time is that jConnect doesn't know what kind of
server it will be connected to beforehand (SqlServer 10.0, 11.0, ...,
SQL Anywhere 5.5, Jaguar CTS, Omni-->DB2, DirectConnect-->Oracle, etc.).

The approach using sp_mda to dynamically find out how to access
metadata from a server will be easier to maintain and can be
customized by the various servers without requiring synchronized
changes in jConnect.

> I notice that you need to have stored procedures loaded on any Sybase
> database inorder to get jConnect metadata classes to work.
>
> Is this a long term solution to the JDBC metadata interfaces for
> jConnect? This seems like an unnecessary implementation - couldn't this
> be done by passing query strings at run-time? It also adds a
> configuration burden to any Sybase database that you want to use
> meta-data + JDBC + jConnect on?

We are working with our Systems Management group to make this
configuration burden lighter by providing tools for this in the
next release.

>
> If the answer about this being a long-term solution is yes, could you
> explain why this approach was taken? Can you also verify that this is a
> jdbc-compliant solution?

The JDBC standard is silent on database configuration issues.

>
> JDBC's meta-data are a great idea - I am concerned that the jConnect
> implementation lessens the usefulness of these interfaces.
>
> Thanks!
>
> Ted
>
> P.S. I hope my posting here is not a re-hash of old postings, I didn't
> see any in this vein...