Job status is not updating

Hello all,
I have a strange and annoying problem with SQL Server 2000 SP3
(I can't upgrade to SP4 at this moment.)
I have a maintenance plan consisting of three scheduled jobs.
Starting couple of weeks ago the Agent fails to update the
last execution time and job outcome for these jobs.
I thought the problem was with the maintenance palns - as I added
extra steps - but recreating the plans did not help.
The jobs are executed - I can see the job outcomes in a form of
created backup files. The Maintenance Plan History also confirms
the successful execution.
But the last run date/time is 0 and the job outcome is 5 - unknown.
Both the Server and the Agent services are running under Local System
account. Agent connects with Windows integrated security.
Any ideas why and what needs to be done to fix?
TIA,
Y.S.Hello,
We found that similar issue is caused by that the TCP/IP Port had a
different values in the Client and the Server Network utilities.
I suggest that you make same port settings for server/client netowrk
utility and restart the SQL Server /Agent services to test the situation.
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
========================================
=============
This posting is provided "AS IS" with no warranties, and confers no rights.|||Peter Yang [MSFT] wrote:
> Hello,
> We found that similar issue is caused by that the TCP/IP Port had a
> different values in the Client and the Server Network utilities.
> I suggest that you make same port settings for server/client netowrk
> utility and restart the SQL Server /Agent services to test the situation.
In fact, the ports were exactly the same, that is 1433, but
thank you anyway - I will be aware of such problem.
However, I was able to fix the problem by connecting the Agent with
'sa' account (it was using integrated security running under Local System.)
Strange, as I never before (and we have 40+ SQL servers in the
datacenter, many of which use integrated security) experienced
anything like this.
Again, the problem was only in status update - the job itself was
executed successfully.
YuraS

> Best Regards,
> Peter Yang
> MCSE2000/2003, MCSA, MCDBA
> Microsoft Online Partner Support
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ========================================
=============
> This posting is provided "AS IS" with no warranties, and confers no rights
.
>|||Hello,
You mean you connect to SQL server from EM as sa and and the issue does not
exist? Or you mean you start SQL agent service as a domain account with
system admin role?
Based on my further research, I found the following known issue about job
status
831366 PRB: Job Status is Not Refreshed When You Connect Using Incorrect
Case for the Login Name
http://support.microsoft.com/defaul...kb;EN-US;831366
Please check if this apply to your situation
Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
========================================
=============
This posting is provided "AS IS" with no warranties, and confers no rights.sql

Job status is not updating

Hello all,
I have a strange and annoying problem with SQL Server 2000 SP3
(I can't upgrade to SP4 at this moment.)
I have a maintenance plan consisting of three scheduled jobs.
Starting couple of weeks ago the Agent fails to update the
last execution time and job outcome for these jobs.
I thought the problem was with the maintenance palns - as I added
extra steps - but recreating the plans did not help.
The jobs are executed - I can see the job outcomes in a form of
created backup files. The Maintenance Plan History also confirms
the successful execution.
But the last run date/time is 0 and the job outcome is 5 - unknown.
Both the Server and the Agent services are running under Local System
account. Agent connects with Windows integrated security.
Any ideas why and what needs to be done to fix?
TIA,
Y.S.Hello,
We found that similar issue is caused by that the TCP/IP Port had a
different values in the Client and the Server Network utilities.
I suggest that you make same port settings for server/client netowrk
utility and restart the SQL Server /Agent services to test the situation.
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================This posting is provided "AS IS" with no warranties, and confers no rights.|||Peter Yang [MSFT] wrote:
> Hello,
> We found that similar issue is caused by that the TCP/IP Port had a
> different values in the Client and the Server Network utilities.
> I suggest that you make same port settings for server/client netowrk
> utility and restart the SQL Server /Agent services to test the situation.
In fact, the ports were exactly the same, that is 1433, but
thank you anyway - I will be aware of such problem.
However, I was able to fix the problem by connecting the Agent with
'sa' account (it was using integrated security running under Local System.)
Strange, as I never before (and we have 40+ SQL servers in the
datacenter, many of which use integrated security) experienced
anything like this.
Again, the problem was only in status update - the job itself was
executed successfully.
YuraS
> Best Regards,
> Peter Yang
> MCSE2000/2003, MCSA, MCDBA
> Microsoft Online Partner Support
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> =====================================================> This posting is provided "AS IS" with no warranties, and confers no rights.
>|||Hello,
You mean you connect to SQL server from EM as sa and and the issue does not
exist? Or you mean you start SQL agent service as a domain account with
system admin role?
Based on my further research, I found the following known issue about job
status
831366 PRB: Job Status is Not Refreshed When You Connect Using Incorrect
Case for the Login Name
http://support.microsoft.com/default.aspx?scid=kb;EN-US;831366
Please check if this apply to your situation
Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Job status is not updating

Hello all,
I have a strange and annoying problem with SQL Server 2000 SP3
(I can't upgrade to SP4 at this moment.)
I have a maintenance plan consisting of three scheduled jobs.
Starting couple of weeks ago the Agent fails to update the
last execution time and job outcome for these jobs.
I thought the problem was with the maintenance palns - as I added
extra steps - but recreating the plans did not help.
The jobs are executed - I can see the job outcomes in a form of
created backup files. The Maintenance Plan History also confirms
the successful execution.
But the last run date/time is 0 and the job outcome is 5 - unknown.
Both the Server and the Agent services are running under Local System
account. Agent connects with Windows integrated security.
Any ideas why and what needs to be done to fix?
TIA,
Y.S.
Hello,
We found that similar issue is caused by that the TCP/IP Port had a
different values in the Client and the Server Network utilities.
I suggest that you make same port settings for server/client netowrk
utility and restart the SQL Server /Agent services to test the situation.
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.
|||Peter Yang [MSFT] wrote:
> Hello,
> We found that similar issue is caused by that the TCP/IP Port had a
> different values in the Client and the Server Network utilities.
> I suggest that you make same port settings for server/client netowrk
> utility and restart the SQL Server /Agent services to test the situation.
In fact, the ports were exactly the same, that is 1433, but
thank you anyway - I will be aware of such problem.
However, I was able to fix the problem by connecting the Agent with
'sa' account (it was using integrated security running under Local System.)
Strange, as I never before (and we have 40+ SQL servers in the
datacenter, many of which use integrated security) experienced
anything like this.
Again, the problem was only in status update - the job itself was
executed successfully.
YuraS

> Best Regards,
> Peter Yang
> MCSE2000/2003, MCSA, MCDBA
> Microsoft Online Partner Support
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ================================================== ===
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
|||Hello,
You mean you connect to SQL server from EM as sa and and the issue does not
exist? Or you mean you start SQL agent service as a domain account with
system admin role?
Based on my further research, I found the following known issue about job
status
831366PRB: Job Status is Not Refreshed When You Connect Using Incorrect
Case for the Login Name
http://support.microsoft.com/default...b;EN-US;831366
Please check if this apply to your situation
Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.

Job owned by a non-sysadmin fails to run

Hi,
The preblem has been already discussed but none of answers help me.
I have a SQL Server 2000 SP4. Users that are not sysadmins create jobs for
SQL Server Agent. These jobs consist of a single CmdExec step.
As advised in many posts I created a Proxy SQL Server Agent account
(sqlproxy) but this did not help me, the jobs still fail to run. This
account is a windows account. I made this account belong to the sysadmins
role of SQL Server.
Both SQL Server and SQL Server Agent run under a special account
(sqlservice).
I added the account sqlservice to Administrators as advised in the article
http://support.microsoft.com/kb/833559 and even added to Administrators the
account sqlproxy, although the article states I did not have to.
The message I get in EventLog is like below:
-- message start
SQL Server Scheduled Job '<job name>' (0xEFC686299E5B9249957CC5FCF5C782C4) -
Status: Failed - Invoked on: 2006-12-18 12:06:06 - Message: The job failed.
The Job was invoked by User <domain>\<user>. The last step to run was step
1 (<step name> ).
-- message end
The command of the CmdExec step runs fine if I login as user as well as
sqlproxy.
I set the output file in advanced properties of the CmdExec step but did not
see in that file anything. Looks like the job does not start at all.
When I add user acocunt to the group Administrators the job runs
successfully, but this is definitely not an option.
I would appreciate any help as I run out of ideas already.Try changing the owner of the job to SA or another sysadmin.
Ivan Gerken wrote:
> Hi,
> The preblem has been already discussed but none of answers help me.
> I have a SQL Server 2000 SP4. Users that are not sysadmins create jobs for
> SQL Server Agent. These jobs consist of a single CmdExec step.
> As advised in many posts I created a Proxy SQL Server Agent account
> (sqlproxy) but this did not help me, the jobs still fail to run. This
> account is a windows account. I made this account belong to the sysadmins
> role of SQL Server.
> Both SQL Server and SQL Server Agent run under a special account
> (sqlservice).
> I added the account sqlservice to Administrators as advised in the article
> http://support.microsoft.com/kb/833559 and even added to Administrators th
e
> account sqlproxy, although the article states I did not have to.
> The message I get in EventLog is like below:
> -- message start
> SQL Server Scheduled Job '<job name>' (0xEFC686299E5B9249957CC5FCF5C782C4)
-
> Status: Failed - Invoked on: 2006-12-18 12:06:06 - Message: The job failed
.
> The Job was invoked by User <domain>\<user>. The last step to run was ste
p
> 1 (<step name> ).
> -- message end
> The command of the CmdExec step runs fine if I login as user as well as
> sqlproxy.
> I set the output file in advanced properties of the CmdExec step but did n
ot
> see in that file anything. Looks like the job does not start at all.
> When I add user acocunt to the group Administrators the job runs
> successfully, but this is definitely not an option.
> I would appreciate any help as I run out of ideas already.|||This quick solution is not an option.
Jobs are created from an external application (Business Desk of Commerce
Server 2002). A created job is owned by the user logged in to the
application (using win integrated authentication).
I definitely don't want to give users administrative privileges.
"PSPDBA" <DissendiumDBA@.gmail.com> wrote in message
news:1166704870.838450.230270@.f1g2000cwa.googlegroups.com...
> Try changing the owner of the job to SA or another sysadmin.
>|||For debugging, try temporarily changing the job owner to 'sa' as PSPDBA
suggested. If the job still fails, then the problem is related to running
as a job rather than a security issue.
Exactly what does the CmdExec step do? Are mapped drives accessed?
Hope this helps.
Dan Guzman
SQL Server MVP
"Ivan Gerken" <testivan@.waterproof.nl> wrote in message
news:uE$3GeRJHHA.420@.TK2MSFTNGP06.phx.gbl...
> This quick solution is not an option.
> Jobs are created from an external application (Business Desk of Commerce
> Server 2002). A created job is owned by the user logged in to the
> application (using win integrated authentication).
> I definitely don't want to give users administrative privileges.
> "PSPDBA" <DissendiumDBA@.gmail.com> wrote in message
> news:1166704870.838450.230270@.f1g2000cwa.googlegroups.com...
>|||Looks like I have a problem with CmdExec jobs in general.
I changed the step command to "dir c:\temp" and it ran fine when owned by an
admin but failed when owned by a user. In case of being owned by a user even
the output file was not created. The folder c:\temp has "full control"
permission granted to everyone.
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:42FF0C9C-4AFC-42AF-9464-0931A1DDE13B@.microsoft.com...
> I'm starting to run out of ideas. Do you have any CmdExec job steps that
> successfully run as non-sysadmin users or is it just dmlrun.exe that has
> the problem?
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP|||Lets make sure I have the relevant details right since so much has been
discussed in this thread:
- SQL Server service and SQL Server Agent service run under the same
account
- The account is a member of the local administrators group
- xp_cmdshell runs fine when involed by non-sysadmins
- CmdExec jobs fail for jobs owned by non-sysadmins
What I find strange is that xp_cmdshell works but CmdExec doesn't. I can
see how this might be the case if you used different service accounts and
the SQL Agent service account lacked the advanced user rights (e.g. 'act as
part of the operating system' and 'replace a process-level token') that are
needed to switch security context to the proxy account.
Can you double-check to ensure the same service account is used for SQL
Server and SQL Server Agent services? If you have made changes to service
account security, have you since restarted the service? In some cases, a
server restart in needed in order for security changes to fully take affect.
Happy Holidays
Dan Guzman
SQL Server MVP
"Ivan Gerken" <testivan@.waterproof.nl> wrote in message
news:%239rDNPAKHHA.2236@.TK2MSFTNGP02.phx.gbl...
> Looks like I have a problem with CmdExec jobs in general.
> I changed the step command to "dir c:\temp" and it ran fine when owned by
> an admin but failed when owned by a user. In case of being owned by a user
> even the output file was not created. The folder c:\temp has "full
> control" permission granted to everyone.
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
> news:42FF0C9C-4AFC-42AF-9464-0931A1DDE13B@.microsoft.com...
>|||- SQL Server service and SQL Server Agent service run under the same
account
Yes, referred to earlier as sqlservice. However, the services MSSEARCH,
MSSQLServerADHelper, MSSQLServerOLAPService run under Local System (I think
it hardly matters but just in case).
- The account is a member of the local administrators group
Yes, plus OLAP Administrators and Users.
- xp_cmdshell runs fine when involed by non-sysadmins
Yes. User account is a member of Users and Remote Desktop Users.
- CmdExec jobs fail for jobs owned by non-sysadmins
Yes, even after restarting both MSSQLSERVER and SQLSERVERAGENT.
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:A7AC10BD-AE8F-4C96-ADE3-1F1603A38D9C@.microsoft.com...
> Lets make sure I have the relevant details right since so much has been
> discussed in this thread:
> - SQL Server service and SQL Server Agent service run under the same
> account
> - The account is a member of the local administrators group
> - xp_cmdshell runs fine when involed by non-sysadmins
> - CmdExec jobs fail for jobs owned by non-sysadmins
> What I find strange is that xp_cmdshell works but CmdExec doesn't. I can
> see how this might be the case if you used different service accounts and
> the SQL Agent service account lacked the advanced user rights (e.g. 'act
> as part of the operating system' and 'replace a process-level token') that
> are needed to switch security context to the proxy account.
> Can you double-check to ensure the same service account is used for SQL
> Server and SQL Server Agent services? If you have made changes to service
> account security, have you since restarted the service? In some cases, a
> server restart in needed in order for security changes to fully take
> affect.
> --
> Happy Holidays
> Dan Guzman
> SQL Server MVP|||> Yes, even after restarting both MSSQLSERVER and SQLSERVERAGENT.
Have you restarted the server since you added the sqlservice account to the
local Administrator's group? Although not normally required, I've seen
occasions where a restart was needed to pickup the group membership change.
BTW, are there any related messages in the SQL Agent log files?
Hope this helps.
Dan Guzman
SQL Server MVP
"Ivan Gerken" <testivan@.waterproof.nl> wrote in message
news:uVs$ZSQKHHA.2232@.TK2MSFTNGP02.phx.gbl...
>- SQL Server service and SQL Server Agent service run under the same
>account
> Yes, referred to earlier as sqlservice. However, the services MSSEARCH,
> MSSQLServerADHelper, MSSQLServerOLAPService run under Local System (I
> think it hardly matters but just in case).
> - The account is a member of the local administrators group
> Yes, plus OLAP Administrators and Users.
> - xp_cmdshell runs fine when involed by non-sysadmins
> Yes. User account is a member of Users and Remote Desktop Users.
> - CmdExec jobs fail for jobs owned by non-sysadmins
> Yes, even after restarting both MSSQLSERVER and SQLSERVERAGENT.
>
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
> news:A7AC10BD-AE8F-4C96-ADE3-1F1603A38D9C@.microsoft.com...
>|||Dan,
Many thanks for a great hint! I checked SQL Agent log and found there the
following message:
[136] Job <job name> reported: Warning: cannot write logfile
c:\temp\dmout.txt. Error 5 : Access is denied
Then, after I have cleared the "Output file" box the job executed
successfully. So the problem seems to be solved.
However, I find this error very odd because full control is granted to
everyone on c:\temp
Many thanks for your help!
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:C7F5CB7B-970A-4EFF-885C-772ED21ECF0A@.microsoft.com...
> Have you restarted the server since you added the sqlservice account to
> the local Administrator's group? Although not normally required, I've
> seen occasions where a restart was needed to pickup the group membership
> change.
> BTW, are there any related messages in the SQL Agent log files?
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Ivan Gerken" <testivan@.waterproof.nl> wrote in message
> news:uVs$ZSQKHHA.2232@.TK2MSFTNGP02.phx.gbl...
>|||I'm glad you were able to get it sorted out. I'm sorry I didn't suggest
checking the log earlier.

> However, I find this error very odd because full control is granted to
> everyone on c:\temp
The error 5 can be caused by the file being used by another process or that
the read-only attribute is set.
Hope this helps.
Dan Guzman
SQL Server MVP
"Ivan Gerken" <testivan@.waterproof.nl> wrote in message
news:eLhoAacKHHA.3424@.TK2MSFTNGP02.phx.gbl...
> Dan,
> Many thanks for a great hint! I checked SQL Agent log and found there the
> following message:
> [136] Job <job name> reported: Warning: cannot write logfile
> c:\temp\dmout.txt. Error 5 : Access is denied
> Then, after I have cleared the "Output file" box the job executed
> successfully. So the problem seems to be solved.
> However, I find this error very odd because full control is granted to
> everyone on c:\temp
> Many thanks for your help!
>
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
> news:C7F5CB7B-970A-4EFF-885C-772ED21ECF0A@.microsoft.com...
>

JDBC performance on Windows Xp SP2

I wrote a conversion program to convert some dbf data to an sql server 2000.
When I run the program on a Windows 2000 SP4 everything works fine. When
I run the same program on a Windows XP SP2 the program is really slow.
Haven't tried the program on a xp without sp 2. Maybe SP is the problem.
Anyone had the same problem?
On a 2000 machine the program copies up to 100 records a second. The same
program running on a xp machine copies only one record a second!
I tried the latest ms jdbc driver as wel as the open source driver.
No difference, same problem.
It's a sql server 2000 Sp3.
I disabled the xp firewall, but same result. Still to slow.
Both machines (2000 and xp) have the same hardware: pentium IV 2.4 GHz with
512MB ram.
I'm using the sun java 1.5.0_01.
Any idea?
Thanks Davy
Davy,
Have you been able to narrow down at all what is slower? Is it reading
the data from dbf or inserting into SQL Server?
Sue Purkis
DataDirect Technologies
"Davy" <Davy@.discussions.microsoft.com> wrote in message
news:5D7E84B6-DF43-41C3-98FA-6C9AF13E34C8@.microsoft.com...
> I wrote a conversion program to convert some dbf data to an sql server
2000.
> When I run the program on a Windows 2000 SP4 everything works fine. When
> I run the same program on a Windows XP SP2 the program is really slow.
> Haven't tried the program on a xp without sp 2. Maybe SP is the problem.
> Anyone had the same problem?
> On a 2000 machine the program copies up to 100 records a second. The same
> program running on a xp machine copies only one record a second!
> I tried the latest ms jdbc driver as wel as the open source driver.
> No difference, same problem.
> It's a sql server 2000 Sp3.
> I disabled the xp firewall, but same result. Still to slow.
> Both machines (2000 and xp) have the same hardware: pentium IV 2.4 GHz
with
> 512MB ram.
> I'm using the sun java 1.5.0_01.
>
> Any idea?
>
> Thanks Davy
|||Inserting the records into SQL Server.
"Sue Purkis" wrote:

> Davy,
> Have you been able to narrow down at all what is slower? Is it reading
> the data from dbf or inserting into SQL Server?
> Sue Purkis
> DataDirect Technologies
> "Davy" <Davy@.discussions.microsoft.com> wrote in message
> news:5D7E84B6-DF43-41C3-98FA-6C9AF13E34C8@.microsoft.com...
> 2000.
> with
>
>

JDBC for SQL 2000 Service Pack 4?

Am I knuts, or does SQL2k SP4 break the latest set of JDBC drivers? Can
anyone confirm?
oleitch-AT-locustcreek-DOT-com
And by "break" you mean?
Alin.
|||"Fail to work with"
JDBC will not connect (gives the 'End of stream was detected on a read'
error). Was working fine before SP4 (previously SP3).
|||Works fine for me. What is the exact error? Can you connect using OSQL.EXE?
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright SQLDev.Net 1991-2005 All rights reserved.
"end-user" <end-user@.discussions.microsoft.com> wrote in message
news:A01EF57B-01C3-4B84-A9CB-1D3E22E6BE42@.microsoft.com...
> "Fail to work with"
> JDBC will not connect (gives the 'End of stream was detected on a read'
> error). Was working fine before SP4 (previously SP3).
|||The exact error is " java.sql.SQLException: [Microsoft][SQLServer 2000 Driver
for JDBC]End of stream was detected on a read."
On the SQL server, I get a "Connection opened but invalid login packet(s)
sent. Connection closed".
I can't run osql.exe as I'm connecting from a linux box.
|||Can someone confirm that the JDBC drivers (for sp3) can successfully connect
to SQL Server w/ SP4 *when the "force protocol encryption" option is enabled*?
|||end-user wrote:
> Can someone confirm that the JDBC drivers (for sp3) can successfully connect
> to SQL Server w/ SP4 *when the "force protocol encryption" option is enabled*?
Anyone?
|||Anyone what?
|||Alin Sinpalean wrote:
> Anyone what?
>
Can someone confirm that the JDBC drivers (for sp3) can successfully
connect to SQL Server w/ SP4 *when the "force protocol encryption"
option is enabled*?
|||"Force protocol encryption" enabled? The MS driver never did support
SSL encryption. Use jTDS ( http://jtds.sourceforge.net ) or one of the
commercial drivers for that.
Disclaimer: I'm a jTDS developer.
Alin.

JDBC driver for SQLServer 2000 SP4

Can anyone tell me whether it is better to use the JDBC driver 2000 for SQL Server 2000 + SP4 or is it better to use the newest JDBC driver 2005 ? What would be the advantage or disadvantage.

Thanks, Marcel

Marcel:

The main benefit of the new driver is that it's in active development with a full team working on new driver updates and features for the latest Java vms and SQL Server database versions. More importantly, the older SQL Server 2000 driver is in Extended Support mode and is not actively serviced, while SQL Server 2005 driver is actively supported and the development team can be much more responsive on customer issues.

Other key benefits of the SQL Server 2005 driver are that it is

-faster

-more secure (i.e. integrated authentication feature)

-supported against SQL Server 2005 with the new database features (i.e. db mirroring support)

-freely redistributable

Unless you have existing applications that depend on a feature tic from the older driver and aren't worth upgrading to use the new driver, we strongly recommend that you use the newer driver.

-shelby

Microsoft SQL Server Data Programmability

JDBC driver for SQLServer 2000 SP4

Can anyone tell me whether it is better to use the JDBC driver 2000 for SQL Server 2000 + SP4 or is it better to use the newest JDBC driver 2005 ? What would be the advantage or disadvantage.

Thanks, Marcel

Marcel:

The main benefit of the new driver is that it's in active development with a full team working on new driver updates and features for the latest Java vms and SQL Server database versions. More importantly, the older SQL Server 2000 driver is in Extended Support mode and is not actively serviced, while SQL Server 2005 driver is actively supported and the development team can be much more responsive on customer issues.

Other key benefits of the SQL Server 2005 driver are that it is

-faster

-more secure (i.e. integrated authentication feature)

-supported against SQL Server 2005 with the new database features (i.e. db mirroring support)

-freely redistributable

Unless you have existing applications that depend on a feature tic from the older driver and aren't worth upgrading to use the new driver, we strongly recommend that you use the newer driver.

-shelby

Microsoft SQL Server Data Programmability