Error deploying JDBC driver for SQL Server 2005

[Former Member]

Hi all

I'm trying to deploy a JDBC driver for MS SQL Server 2005 (downloaded [here|http://www.microsoft.com/downloads/details.aspx?familyid=C47053EB-3B64-4794-950D-81E1EC91C1BA&displaylang=en]). When I try to deploy it according to the instructions found [here|http://help.sap.com/saphelp_nwce10/helpdata/en/51/735d4217139041e10000000a1550b0/frameset.htm] it fails.

The error in the logs doesn't give any useful information though. It only says Error occurred while deploying component ".\temp\dbpool\MSSQL2005.sda".

Has anyone else deployed a driver for SQL Server 2005, or perhaps have any suggestions of what else I could try?

Thanks

Stuart

[Former Member · Accepted solution]

I'm getting a similarly unhelpful error message when trying to create a new Data Source using the default driver: Error occurred while deploying component ".\temp\dbpool\TRACKER.xml.sda".

I'm assuming this should work, seeing as the SAP DB also runs on MSSQL - so the driver should be able to be shared easily.

Does anyone know where I can find better logs (these were found in the SAP Logs in NWA)? The one's that I've copied into this thread are all I can find, and they add absolutely no value to the troubleshooting process.

[Vlado · Accepted solution]

Hi Stuart,

You could look into the defaultTrace.trc under ../j2ee/cluster/server0/log.

Can you also post the contents of TRACKER.xml?

Regards,

\-- Vladimir

[Former Member · Accepted solution]

Hi Vladimir

Thanks for your suggestion. I didn't check the defaultTrace.trc file because I was under the impression that it shows the same information as the log viewer within NWA. Clearly my assumption was wrong about that. Thanks for clearing that up!

I did manage to find the problem within the defaultTrace.trc file, and it was based on authorisations. Creating a Data Source doesn't seem to be fully programmatically integrated into NetWeaver, as it creates a file and then deploys this into NetWeaver (hence the Tracker.xml.sda file mentioned in the error). The user account I was using didn't have permissions to deploy, so I used a different user account and it worked perfectly.

I think the error should've been clearer, as the developer that added this functionality would've received an exception relating to authorisations (surely). In addition to this, my user account has been assigned to the NWA_SUPERADMIN role, so surely this should encompass every possible action that can be performed within NWA? It seems contradictory to give someone access to NWA, but then prevent them from performing all actions within it? Surely permission to deploy (when used within NWA) is implied when a user is granted NWA_SUPERADMIN rights?

Anyway, the solution has been found - but I do suggest that better error handling be built into the product as simple errors like this can cost a lot of unecessary time in troubleshooting.

Thanks again for your help!

Cheers

Stuart

[Vlado · Accepted solution]

Thank you very much for the feedback, Stuart!

Actually, the Log Viewer does show the information from the default trace (and other log and trace files). It might have been an issue of filtering or something that you couldn't see it there.

I'll check the authorization related issues with the relevant groups at our side.

Cheers,

\-- Vladimir

[Former Member · Accepted solution]

Oh quite right. I was looking at "SAP Logs" instead of "Default Trace" in the Log Viewer, which explains why I wasn't seeing the full stack trace of the exception.

A number of errors were logged, and some appeared under SAP Logs, and others under Default Trace.

Thanks for your help and also for looking into the authorisation issues. I'm sure it'll help others later down the line that may have problems with the same thing as I have.

[Vlado · Accepted solution]

Hi Stuart,

I'm following up on the NWA_SUPERADMIN authorization issues here.

Actually, NWA incorporates a so called granularity concept with regards to providing access to specific functionality/operations within NWA to certain UME roles. This means that there are roles which have full access to change data, and others with read-only access. And of course, something in between, that is, write access but only to some of the functionality.

Now, despite its name, the NWA_SUPERADMIN role is not granted exclusive access to all functionality. But we discussed the issue and concluded that it should be granted full access to the Application Resources plugin. It will be implemented in one of the upcoming releases.

Thanks again for pointing out this issue to us!

\-- Vladimir

[Former Member · Accepted solution]

Hi Vladimir

That's excellent news! Thanks for the effort you've put into this. I'm very impressed with how seriously these issues are dealt with, specifically within the Java EE aspects of SAP.

May I make two suggestions on this topic:

1. Given that NWA has such granular security permissions, please could the security error be shown when it is raised? This would help immediately identify that the problem isn't actually a product error, but rather a missing security permission (and thus save us time and reduce your support calls).

2. Please could the role permissions be clearly documented (perhaps they already are, and I just couldn't find the docs?) so we know what is and isn't included in the role. The name is very misleading, as a "superadmin" is generally understood to have no limitation on their rights - so clear documentation on what is in-/excluded would be most helpful.

On a related topic, I came across another issue like this that may warrant your attention (while you're already looking into NWA security issues). I logged a support query about it (ref: 0120025231 0000753421 2008) in case you can retrieve details there (screenshots, logs, etc.). It's basically a similar security constraint when trying to create a Destination. I'm not sure if this is something you would like to include as standard permissions within the NWA_SUPERADMIN role or not, but I think it's worth consideration.

Thanks again for your help!

Cheers

Stuart

[Vlado · Accepted solution]

Hi Stuart,

I think all your points are valid.

On 1) - This basically implies better error reporting in NWA. I agree wtih you that it should be improved.

On 2) - I already asked my colleagues to do this. Should I say that it was misleading to me too?

On access to creating Destinations - from my point of view it's the same as with Application Resources. I'll let my NWA colleagues look into this.

Thanks again for all your valuable feedback!

\-- Vladimir