DBWrite Step- enters SQL Error Branch

Unanswered Question
Nov 2nd, 2008


On CRS server(IPCCX5.0), I am trying to update a table(this Table is not under db_cra database) with DBwrite step, the script enters the SQL Error branch when run in Debug mode.

The same script works fine when executed in the Table from SQL Enterprise Manager.

Any idea why is this so?


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3.5 (2 ratings)
sferland Mon, 11/03/2008 - 06:40

Please activate the debug tracing and look in your MIVR logs for the SQL error.

Most of the time, this will be an authentication or permission errors.

ra_jeshkalra_2 Mon, 11/03/2008 - 12:11

What error I should look for in the logs.Do I need to enable any special tracing

By the way I created a new DB and Table on the CRS, Is this o.k. or I should create a new table under db_cra database?

What is recommended?


ra_jeshkalra_2 Mon, 11/03/2008 - 22:50

I get the error: State=S0002,SQL Error Code=208

Detailed logs follows:-

17352: Nov 04 14:54:42.455 SGT %MIVR-SS_TEL-7-UNK:Call.answered() JTAPICallContact[id=11,implId=259/1,inbound=false,App name=dialer,task=17000000006,session=34000000006,seq num=0,cn=null,dn=null,cgn=3000,ani=null,dnis=null,clid=null,atype=OUTBOUND,lrd=null,ocn=3000,route=TR[num=0000],TP=4061]

17353: Nov 04 14:54:42.627 SGT %MIVR-SS_DB-3-EXECUTE_SQL_UPDATE_EXCEPTION:Exception occured while executing SQL Update: SQL State=null,SQL Error code=null,Connection #=null

17354: Nov 04 14:54:42.627 SGT %MIVR-DB_STEPS-3-EXECUTE_SQL_UPDATE_EXCEPTION:Error during executing SQL Update: Task ID=17000000006,Step Name=DB Write,SQL State=S0002,SQL Error Code=208

17355: Nov 04 14:54:45.518 SGT %MIVR-ICD_CTI-7-UNK:ClientConnMgr: accepted a client and client is connected at: Socket[addr=,port=51535,localport=42027]

Any idea what is the issue?


Clifford McGlamry Tue, 11/04/2008 - 21:11

If you create a new database and table, you're going to have to configure it with CRS in the AppAdmin pages. You'll have to have set up an ODBC connection for it to use, and define the user name and password for access.

once this is done, you can tackle your script. You have to have the DB Resource successfully able to poll for the database schema before it's going to work at all. once you can get this, you should then make sure your query will run on the test tab.

If it runs in enterprise manager, but not in CRS, you have a config problem. From what you're describing, you need to verify your setup and make sure you've gotten the prerequisite work done for this to work.

ra_jeshkalra_2 Tue, 11/04/2008 - 21:36

Hi cmcqlamry,

thanks , I already fixed this issue.The issue was with the mode of authentication with the database server.

I was trying to create the DB/table on the CRS server, where SQL is installed as "windows authentication mode", instead of mixed mode.

But if we write to enterprise DB on external server where SQl is in mixed mode, this works fine.

If you have to create a new DB, I believe Cisco doesn't support/recommend to create on CRS server!!

Any views on this?

Genereally do you create a new DB/table on an external server?


Clifford McGlamry Wed, 11/05/2008 - 05:12

That's a really good question. The answer is that it depends on what you're doing.

If you have a high availability solution, then you've purchased a full blown SQL server install as part of the solution anyway. The danger in loading another database on the CRS server is that if you load down the server doing non CRS stuff, it may negatively impact server processing.

However, if it is a simple read or simple write (i.e. no complex SQL involved, and the tables are small and/or static), it shouldn't be a problem. But if you are dealing with large tables or tables that are going to grow continuously, I'd strongly suggest moving them to an external server.

Just remember that the CRS server's primary function is running your call center. As long as you aren't bogging down that functionality, you can do pretty much whatever you want. Cisco recommends that you not do this, but if you're storing things like open/close times or VIP pin numbers for the support desk, I've not had issues with it.


This Discussion