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.

procName, lineNum - how to get

4 posts in JDBC Connect (product renamed to JConnect) Last posting was on 1997-10-01 11:34:38.0Z
Andrew Schonberger Posted on 1997-09-06 10:47:45.0Z
From: andrew_sc@hotmail.com (Andrew Schonberger)
Subject: procName, lineNum - how to get
Date: Sat, 06 Sep 1997 10:47:45 GMT
Message-ID: <34113454.720781@forums.powersoft.com>
X-Newsreader: Forte Free Agent 1.1/32.230
Newsgroups: sybase.public.jdbcconnect
Lines: 40
Path: forums-1-dub!forums-master.sybase.com!forums.powersoft.com
Xref: forums-1-dub sybase.public.jdbcconnect:309
Article PK: 252061

With the Debug feature turned on, I'm getting lines like:

serverName='myserver', procName='myproc', lineNum=N

These are of great help when chasing a bug. In one case,
this message accurately pinpointed the line number of a
stored proc which raised an error while executing two
levels below a trigger. Isn't JDBC great !

But having to turn on Debug is often a pain. Is there any
way to make this information available to an exception
processing routine? Currently, I've found no way for
accessing procName/lineNumber programmatically. It would
be great for a program to get access to procname/Linenumber,
and display it along with the error message.

I'm probably requesting an improvement which is neither part
of the JDBC standard, not part of Sybase tradition. With
CtLib/DbLib, neither Powerbuilder nor Artisan are displaying
the originating procname/lineNumber when an error occurs.
But such an extension would provide a competitive advantage
for jConnect over other JDBC drivers. And it shouldn't be
difficult to implement: after all, the information is already
present.

Please note that turning on Debug is not always practicable.
When an application is deployed in the field, we cannot expect
end-users to manipulate large debug-log files. In my case,
I was fighting a third party package based on JDBC. I had no
access to the source. The only way to turn on Debug was to
write my own Java class, call Debug(), and then call the
main() method of that third part package.

Andrew Schonberger


David Clegg Posted on 1997-09-15 16:59:50.0Z
Message-ID: <341D6986.2360B905@sybase.com>
Date: Mon, 15 Sep 1997 09:59:50 -0700
From: David Clegg <davec@sybase.com>
X-Mailer: Mozilla 3.01 (X11; I; Linux 1.2.13 i586)
MIME-Version: 1.0
To: Andrew Schonberger <andrew_sc@hotmail.com>
Subject: Re: procName, lineNum - how to get
References: <34113454.720781@forums.powersoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Newsgroups: sybase.public.jdbcconnect
Lines: 53
Path: forums-1-dub!forums-master.sybase.com!forums.powersoft.com
Xref: forums-1-dub sybase.public.jdbcconnect:279
Article PK: 252031

We are already working on this feature -- we will provide
com.sybase.jdbc.SybSQLException and SybSQLWarning subclasses
of SQLException and SQLWarning. These subclassed exceptions
will provide additional methods for accessing this non-standard
error message info we get from the server. We'll post documentation
here and in the 'whatsnew' page when this is available.

Hope to have it contained in the next update of jConnect2.2
by the end of this week (9/19/97).

dave

>
> With the Debug feature turned on, I'm getting lines like:
>
> serverName='myserver', procName='myproc', lineNum=N
>
> These are of great help when chasing a bug. In one case,
> this message accurately pinpointed the line number of a
> stored proc which raised an error while executing two
> levels below a trigger. Isn't JDBC great !
>
> But having to turn on Debug is often a pain. Is there any
> way to make this information available to an exception
> processing routine? Currently, I've found no way for
> accessing procName/lineNumber programmatically. It would
> be great for a program to get access to procname/Linenumber,
> and display it along with the error message.
>
> I'm probably requesting an improvement which is neither part
> of the JDBC standard, not part of Sybase tradition. With
> CtLib/DbLib, neither Powerbuilder nor Artisan are displaying
> the originating procname/lineNumber when an error occurs.
> But such an extension would provide a competitive advantage
> for jConnect over other JDBC drivers. And it shouldn't be
> difficult to implement: after all, the information is already
> present.
>
> Please note that turning on Debug is not always practicable.
> When an application is deployed in the field, we cannot expect
> end-users to manipulate large debug-log files. In my case,
> I was fighting a third party package based on JDBC. I had no
> access to the source. The only way to turn on Debug was to
> write my own Java class, call Debug(), and then call the
> main() method of that third part package.
>
> Andrew Schonberger


Lance Andersen Posted on 1997-10-01 11:34:38.0Z
Message-ID: <3432354E.7AD@sybase.com>
Date: Wed, 01 Oct 1997 07:34:38 -0400
From: Lance Andersen <lancea@sybase.com>
X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4m)
MIME-Version: 1.0
Subject: Re: procName, lineNum - how to get
References: <34113454.720781@forums.powersoft.com> <341D6986.2360B905@sybase.com>
Content-Type: multipart/mixed; boundary="------------74C85B9C76DC"
Newsgroups: sybase.public.jdbcconnect
Lines: 233
Path: forums-1-dub!forums-master.sybase.com!forums.powersoft.com
Xref: forums-1-dub sybase.public.jdbcconnect:208
Article PK: 251960


David Clegg wrote:
>
> We are already working on this feature -- we will provide
> com.sybase.jdbc.SybSQLException and SybSQLWarning subclasses
> of SQLException and SQLWarning. These subclassed exceptions
> will provide additional methods for accessing this non-standard
> error message info we get from the server. We'll post documentation
> here and in the 'whatsnew' page when this is available.
>
> Hope to have it contained in the next update of jConnect2.2
> by the end of this week (9/19/97).
>
> dave

I have appended a program which demonstrates the new jConnect 2.2
classes SybSQLException and SybSQLWarning.


This sample will be incorporated shortly with the other new samples
that we are providing with jConnect 2.2 and jConnect 3.0

Enjoy!

-Lance
===============================================================================
Lance J. Andersen Email: lancea@sybase.com
Sybase Technical Support Phone:(617) 564-6336
77 South Bedford Street Fax: (617) 564-6148
Burlington, MA 01803

The Dark Knight Returns!!! Let's Go Penguins!!!
===============================================================================

/* SybException.java Sybase Product Support group, 06/01/97
* Copyright (c) 1997, Sybase., Emeryville, CA 94608
* All Rights Reserved
*
* TITLE: SybException.java
*
* START-HISTORY:
*
* 01 Jun 97 edit 0 - Lance Andersen.
* Initial coding.
*
* END-HISTORY
*
* START-DESCRIPTION:
*
* SybException class demonstrates how to use the SybSQLException
* class which extends SQLException and the SybSQLWarning class
* which extends SQLWarnings.
*
* The program also demonstrates how to obtain the output from the
* T-SQL print command via SybSQLWarning.
*
* SybException may be invoked with the optional parameters:
* -U username
* -P password
* -D debuglibraries
* -S server
*
*
* END-DESCRIPTION
*/

import java.io.*;
import java.sql.*;
import java.util.*;
import com.sybase.jdbc.*;
import com.sybase.utils.Debug;

class SybException {

static String _user = "sa";
static String _password = "";
static String _url = "jdbc:sybase:Tds:alder:6689/victimdb";


public static void main (String args[]) {

String createQuery = "create table #test(f1 int, f2 char(10))";
String insertQuery = "insert #test values(1,NULL)";

// Parse the command line

if (!processCommandline(args))
{
System.out.println(
"Syntax:\n" +
"\tSybException [-U <username>] [-P <password>] " +
" [-S <servername>]\n\t\t [-D <debug-class-list>]\n");
System.exit(1);
}


try {

// Load the Sybase Driver

Class.forName("com.sybase.jdbc.SybDriver");


// Attempt to connect to a driver.

Connection con = DriverManager.getConnection(_url, _user, _password);

// If we were unable to connect, an exception
// would have been thrown. So, if we get here,
// we are successfully connected to the URL

// Check for, and display and warnings generated
// by the connect.

checkForWarning (con.getWarnings ());

execDDL(con, "print 'hello world'");
// Create our table

execDDL(con, createQuery);

// Now insert our data

execDDL(con, insertQuery);


// Close the connection

con.close();

}
catch (SQLException ex) {

// A SQLException was generated. Catch it and
// display the error information. Note that there
// could be multiple error objects chained
// together

System.out.println ("\n*** SQLException caught ***\n");

while (ex != null) {

System.out.println ("Error: " + ex.getErrorCode ());
System.out.println ("Message: " + ex.getMessage ());

if(ex instanceof SybSQLException)
{
// This SQLException contains additional Sybase Adaptive
// Server error message info.

SybSQLException eed = (SybSQLException) ex;
System.out.println(" Severity: " + eed.getSeverity());
System.out.println(" Line Number: " + eed.getLineNumber());
System.out.println(" Server Name: " + eed.getServerName());
System.out.println(" Error State: " + eed.getState());
System.out.println("Procedure Name: " + eed.getProcedureName());

}

System.out.println ("SQLState: " + ex.getSQLState ());
ex = ex.getNextException ();
System.out.println ("");
}
}
catch (java.lang.Exception ex) {

// Got some other type of exception. Dump it.

ex.printStackTrace ();
}
}

/*
* checkForWarning
* Checks for and displays warnings. Returns true if a warning
* existed
*/

private static boolean checkForWarning (SQLWarning warn) throws SQLException
{
boolean rc = false;

// If a SQLWarning object was given, display the
// warning messages. Note that there could be
// multiple warnings chained together

if (warn != null) {
System.out.println ("\n *** Warning ***\n");
rc = true;

while (warn != null) {

System.out.println ("Error: " + warn.getErrorCode ());
System.out.println ("Message: " + warn.getMessage ());

if(warn instanceof SybSQLWarning)
{
// This SQLWarning contains additional Sybase Adaptive
// Server error message info.

SybSQLWarning eed = (SybSQLWarning) warn;
System.out.println(" Severity: " + eed.getSeverity());
System.out.println(" Line Number: " + eed.getLineNumber());
System.out.println(" Server Name: " + eed.getServerName());
System.out.println(" Error State: " + eed.getState());
System.out.println("Procedure Name: " + eed.getProcedureName());

}

System.out.println ("SQLState: " + warn.getSQLState ());

System.out.println ("");
warn = warn.getNextWarning ();
}
}
return rc;
}


/*
* execDDL
* Execute a DDL or a DML statement that does not return a ResultSet
*/

private static void execDDL( Connection con, String cmd) throws SQLException
{
System.out.println("Executing: " + cmd);
Statement statement = con.createStatement();
int numrows = statement.executeUpdate(cmd);
checkForWarning(statement.getWarnings());
System.out.println("Number of rows affected= " + numrows);
statement.close();
}

/*
* processCommandline
* Parse the Command Line and set the appropriate options
*/

static private boolean processCommandline(String args[])
{
//* DONE
String arg;
int errorCount = 0;
for (int i = 0; i < args.length; i++)
{
arg = args[i];
if (arg.regionMatches(0, "-", 0, 1))
{
try
{
switch(arg.charAt(1))
{
case 'D':
i++;
try
{
Debug.debug(true, args[i]);
}
catch (IOException ioe)
{
System.out.println(
"Error turning on debugging " + ioe);
}
break;
case 'U':
i++;
_user = args[i];
break;
case 'P':
i++;
_password = args[i];
break;
case 'S':
i++;
_url = args[i];
break;
default:
System.out.println("Invalid command line option: " + arg);
errorCount++;
break;
}
}
catch (ArrayIndexOutOfBoundsException aioobe)
{
System.out.println("missing option argument");
errorCount++;
}
}
else
{
// The syntax has no non "-" arguments
errorCount++;
}
}

return(errorCount == 0);
}

}


Lance Andersen Posted on 1997-09-08 13:33:10.0Z
Message-ID: <3413FE96.6A21@sybase.com>
Date: Mon, 08 Sep 1997 09:33:10 -0400
From: Lance Andersen <lancea@sybase.com>
X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4m)
MIME-Version: 1.0
To: Andrew Schonberger <andrew_sc@hotmail.com>
Subject: Re: procName, lineNum - how to get
References: <34113454.720781@forums.powersoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Newsgroups: sybase.public.jdbcconnect
Lines: 58
Path: forums-1-dub!forums-master.sybase.com!forums.powersoft.com
Xref: forums-1-dub sybase.public.jdbcconnect:305
Article PK: 252058

Thanks for the feature request, I will pass it on to our
development team.


With the 11.5 SQL Server , there is a means for a DBA to see the
SQL that is being sent by a client. This might be another option
for you.


-lance

Andrew Schonberger wrote:
>
> With the Debug feature turned on, I'm getting lines like:
>
> serverName='myserver', procName='myproc', lineNum=N
>
> These are of great help when chasing a bug. In one case,
> this message accurately pinpointed the line number of a
> stored proc which raised an error while executing two
> levels below a trigger. Isn't JDBC great !
>
> But having to turn on Debug is often a pain. Is there any
> way to make this information available to an exception
> processing routine? Currently, I've found no way for
> accessing procName/lineNumber programmatically. It would
> be great for a program to get access to procname/Linenumber,
> and display it along with the error message.
>
> I'm probably requesting an improvement which is neither part
> of the JDBC standard, not part of Sybase tradition. With
> CtLib/DbLib, neither Powerbuilder nor Artisan are displaying
> the originating procname/lineNumber when an error occurs.
> But such an extension would provide a competitive advantage
> for jConnect over other JDBC drivers. And it shouldn't be
> difficult to implement: after all, the information is already
> present.
>
> Please note that turning on Debug is not always practicable.
> When an application is deployed in the field, we cannot expect
> end-users to manipulate large debug-log files. In my case,
> I was fighting a third party package based on JDBC. I had no
> access to the source. The only way to turn on Debug was to
> write my own Java class, call Debug(), and then call the
> main() method of that third part package.
>
> Andrew Schonberger

--
===============================================================================
Lance J. Andersen Email: lancea@sybase.com
Sybase Technical Support Phone:(617) 564-6336
77 South Bedford Street Fax: (617) 564-6148
Burlington, MA 01803

The Dark Knight Returns!!! Let's Go Penguins!!!
===============================================================================