Getting Exception , please help !

Hi all,

I am using MSSQL Server 8.0 , and the driver jtds.jar to connect the database for SQL operation .

I can do all the sql operation .
But after the creation of a trigger for a table , I used the same java program to insert rows into table .

---The java code I used -------
String connectionString = "jdbc:jtds:sqlserver://localhost:1433/master";
try {
Class.forName(jdbcDriverClass);
Connection con = DriverManager.getConnection(connectionString,userN ame,password);
Statement st = con.createStatement();
String query = "insert into tabname values('11','ROBERT')";
st.executeUpdate(query);
} catch (Exception e) { e.printStackTrace(); }
---------------

and got the exception

////////////////////////////////////////////////////////
java.sql.SQLException: executeUpdate can't return a result set
at net.sourceforge.jtds.jdbc.TdsStatement.executeUpda te(Unknown Source)
////////////////////////////////////////////////////////

What will be the problem here ?
Is it bcos of any time out ?
Please help !!!

ThanksPost the trigger.|||CREATE TRIGGER trigName ON tabname for
INSERT , UPDATE , DELETE
AS

DECLARE @.cont varchar(255)
DECLARE @.insRsltCount int
DECLARE @.delRsltCount int
DECLARE @.newVAL_0 char(10)
DECLARE @.newVAL_1 char(10)
SELECT @.insRsltCount = COUNT(*) FROM Inserted WHERE name IS NOT NULL OR num IS NOT NULL
SELECT @.delRsltCount = COUNT(*) FROM Deleted WHERE name IS NOT NULL OR num IS NOT NULL
IF(@.insRsltCount>0) AND (@.delRsltCount=0)
BEGIN
DECLARE INS_CURSOR CURSOR FOR SELECT name, num FROM Inserted
OPEN INS_CURSOR
FETCH NEXT FROM INS_CURSOR INTO @.newVAL_0,@.newVAL_1
WHILE @.@.FETCH_STATUS = 0 AND @.insRsltCount>0
BEGIN

SELECT @.cont = ' echo tabname.name="'+LTRIM(RTRIM(@.newVAL_0))+'" >>D://MyFolder//trigName.dat'
Exec master..xp_cmdshell @.cont
SELECT @.insRsltCount = @.insRsltCount-1
FETCH NEXT FROM INS_CURSOR INTO @.newVAL_0,@.newVAL_1


END
CLOSE INS_CURSOR
DEALLOCATE INS_CURSOR
END|||The usage of xp_cmdshell has been altered with the release of SP3 (SQL2K) and SP4 (7.0). From then on the security context is being verified within the procedure which is extended stored procedure, and if a user who caused (in your case) the trigger to fire does not belong to SYSADMIN server role, - the procedure will not execute.