on 03-09-2009 4:07 PM
Hi
When I try and release a transport on our Development NW04 instance in transaction SE01 I get the error :
'Test call of transport control program (tp) ended with return code 0232'
We are running on NW04 BW on Windows Server 2003 64 Bit/MS SQL 2005, the DIR_TRANS is on our Production instance which is the domain controller.
I've tried to do a TP connect PF=domain controller DBW and it fails with the error :
This is tp version 340.16.24 (release 640, unicode enabled)
Warning: Parameter DBHOST is no longer used.
Warning: Parameter DBNAME is no longer used.
TRACE-INFO: 1: [dev trc ,00000] Mon Mar 09 15:54:18 2009 757 0.000757
TRACE-INFO: 2: [dev trc ,00000] load shared library (dbmssslib.dll), hdl 0 10 0.000767
TRACE-INFO: 3: [dev trc ,00000] using "C:\usr\sap\DBW\SYS\exe\run\dbmssslib.dll" 10 0.000777
TRACE-INFO: 4: [dev trc ,00000] Thread ID:7968 3582 0.004359
TRACE-INFO: 5: [dev trc ,00000] Thank You for using the SLOLEDB-interface 10 0.004369
TRACE-INFO: 6: [dev trc ,00000] Using dynamic link library 'C:\usr\sap\DBW\SYS\exe\run\dbmssslib.dll'
TRACE-INFO: 7: 20 0.004389
TRACE-INFO: 8: [dev trc ,00000] dbmssslib.dll patch info 32 0.004421
TRACE-INFO: 9: [dev trc ,00000] patchlevel 0 7 0.004428
TRACE-INFO: 10: [dev trc ,00000] patchno 152 7 0.004435
TRACE-INFO: 11: [dev trc ,00000] patchcomment Connection check on (0,0) (988711) 9 0.004444
TRACE-INFO: 12: [dev trc ,00000] Local connection used on <SERVER> to named instance: np:<SERVER>\DBW
TRACE-INFO: 13: 85 0.004529
TRACE-INFO: 14: [dev trc ,00000] CopyLocalParameters: dbuser is 'dbw' 9 0.004538
TRACE-INFO: 15: [dev trc ,00000] Provider SQLNCLI could not be initialized. See note #734034 for more information.
TRACE-INFO: 16: 8895 0.013433
TRACE-INFO: 17: [dev trc ,00000] Using provider SQLOLEDB instead. 10 0.013443
TRACE-INFO: 18: [dev trc ,00000] OpenOledbConnection: MARS property was not set. 186 0.013629
TRACE-INFO: 19: [dev trc ,00000] Provider Release:08.10.3959 60092 0.073721
TRACE-INFO: 20: [dev trc ,00000] Provider SQLNCLI could not be initialized. See note #734034 for more information.
TRACE-INFO: 21: 944 0.074665
TRACE-INFO: 22: [dev trc ,00000] Using provider SQLOLEDB instead. 9 0.074674
TRACE-INFO: 23: [dev trc ,00000] Cache sizes: header 104 bytes, 100 names (164000 bytes), 100 dynamic statements (574400 bytes), total 738504 bytes
TRACE-INFO: 24: 7047 0.081721
TRACE-INFO: 25: [dev trc ,00000] Initializing private procedure name cache. 14 0.081735
TRACE-INFO: 26: [dev trc ,00000] procedure cache created/attached 21 0.081756
TRACE-INFO: 27: [dev trc ,00000] Connected to db server : [<SERVER>\DBW] server_used : [np:<SERVER>\DBW], dbname: DBW, dbuser: dbw
TRACE-INFO: 28: 17 0.081773
TRACE-INFO: 29: [dev trc ,00000] pn_id:<SERVER>_DBW_DBWDBW 7 0.081780
TRACE-INFO: 30: [dev trc ,00000] You must use SNAC to access SQL 9.0 or later. See note #734034
TRACE-INFO: 31: 11 0.081791
TRACE-INFO: 32: [dblink ,00419] ***LOG BY2=>sql error 0 performing CON [dblink#2 @ 419]
TRACE-INFO: 33: 147 0.081938
TRACE-INFO: 34: [dblink ,00419] ***LOG BY0=><message text not available> [dblink#2 @ 419]
TRACE-INFO: 35: 14 0.081952
tp returncode summary:
TOOLS: Highest return code of single steps was: 0
ERRORS: Highest tp internal error was: 0232
tp finished with return code: 232
meaning:
connect failed
When I perform a check Transport Tool in STMS the DB connect and offline call checks fail with the error above.
As far as I know, the only thing that happened recently was a restart of the Dev instance happened last Thursday and today we are having peoblems releasing transports.
I can use AL11 on our DEV server to get to the domain controller directories, so it doesn't look like permissions, the TP version has not been modified for a while and is consitant through the landscape.
Thanks for any reply.
Hi
Thanks for the replys.
Looks like security on the C: drive (and especially on the Windows directory) was corrupt. Administrators and system users had no rights - I've now given them full rights to all directories and subdirectories. The TP now works ok, and spurious errors we were getting for MMC & R3trans are also working.
I agree R3trans -d if a useful command, I used that later on after the advice and that was also failing to connect, so I knew it was something strange ! TP was working at 10am and then developers were saying that transports could not be released at 11am and we were getting the TP error, so I was confident it was not the restart 5 days ago.
I am now investigating how the C drive permissions were changed !
Thanks.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Wow, it's almost scary to respond now but Mr. Reyes is right. The answer Lolla gave has nothing to do with the issue here.
I've seen this a lot and it has been different problems. One of the ones my notes say to check is note: 165708. This has to do with your transport profile getting screwed up.
Beyond that, I see this happen when I do a refresh. This may or may not help but here is what I see when I do refreshes.
1. remove the system from your TMS at the domain controller.
2. In your refreshed system, try to add yourself back to the domain.
3. Then go back to the domain controller and "approve" the new system. Then distribute the new model.
There's something else that causes this and I can't think of it off the top of my head but I'll try to remember and send it on if this doesn't work.
By the way. R3TRANS -x or -d is a great tool for determining if your app can connect to the database. But I don't know of any way it relates to transports.
User | Count |
---|---|
94 | |
11 | |
11 | |
10 | |
9 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.