changes to database blow up script....

[mbausenwein]

Hello,

I have IPCC 3.5 running.    We have a script where calls are sent to different queues based on a code that the caller enters.   We then use that code to perform a database lookup to get the CSQ and the voicemail box to send calls that callers do not want to wait in queue for.   They wanted the ability to send a call to a different extension per queue if the caller was on hold for more than 4 minutes.

I was able to setup the if/then statement to hardcode the same extension for all.  After that, we edited the table (teams) and added the column called call_redirect as a string.  I changed the DBget function to add the field name to local variable setting.   This is the same variable that we were using before when we transferred all calls after 4 minutes.

Once we changed this, the script bombs.    After entering the code that should be able to be looked up, instead of being transferred to the queue, we hear a phone ringing, then we hear that we are experiencing system error.

Am I missing something?

How can I troubleshoot this and debug it?

Thanks

Mike

[Aaron Harrison]

Hi

Log into the script editor, and do a reactive debug of the script.

Type tools/reactive debug, then enter the name of the script into the box. The timeout is the amount of time you then have to launch a call to the script, which you can then step through using F8. When you call it you will just get ringing, and a script debug window should appear in the editor. You press F8, and the ringing will stop when you reach the 'Accept' step. Basically step through until it hits the DB, and verify what gets written to the variables window.

You should be able to see when it fails, and get some sort of exception.

If it's not clear report back what you see...

Aaron

Please rate helpful posts...

[mbausenwein]

unable to set the variable with the value returned from the database 9999; nexted exception is java.lang.illegalArgumentExcpetion: type mismatch context variable type-javlang.String value java.lang.Integer

I checked the table definition and the dbget fields and they seem to match.....

[Aaron Harrison]

Hi

That means that you are retrieving an Integer from the DB and trying to apply it to a String variable in your script (or the other way around).

Change your DB to match ideally, or set the returned Integer into a matching variable type in the script, and then you can cast it to the type you want.

Aaron

[James Hawkins]

The script editor has a validate script tool that can be used to check that the script is basically sound (no dangling goto's etc.). Does your script pass validation?

If yes then you can use the Reactive Script feature to step through the script step by step as a call is processed. This should allow you to identify where the script is failing.

From what you have described I suspect that you may need to change the SQL statement in the DB Read step that precedes the DB Get step that you say you have modified.

If you have modified the SQL statement in the DB read step what result do you get if you click the Test button on the SQL tab of the DB Read step in the editor?

[mbausenwein]

upon further inspection the database has the csq defined as integer, but the script is defining queue as string.

When I tried changing the script to match the database, I do not even play any prompts, I just get the system error prompt.

I have an existing script that i copied from.  It uses csq as string even though it is integer on the database.     Do you think changing the database to match the script is a good idea?   I am afraid i might break the existing script i already have that is also using this table....

Mike

[Aaron Harrison]

Hi

Well - what are you storing in the CSQ column? If it's an integer you can only store numbers, and if you have a script that already uses this table OK then I guess this is correct?

As you say, if something else is using this tabel you don't want to dive in and start changing stuff.

You would want to read the integer from the DB into an int in your script... so change the variable type there.

Aaron

[mbausenwein]

we are storing the contact service queue to send the call to.....

I changed my script to have the variable set to integer to match the database.   When I had this setup, the promps would not even play to collect the digits.  I setup a new table in the DB with the same data, but with csq field set to character in both the DB and the script.   This worked for  CSQs not starting with 0, but for ones that started with another number it worked like a champ.  For example if a users enterd 033, then it would then get a system error message.  When I looked at the debugs I would see an error saying csq 400 is invalid.   For grins and giggles, I changed the datatype in the new database table to be integer and left the variable as character and it seems to work.....

Any suggestions to make it work as a character, or should it be an integer?

I guess i figured out why there was a mismatch last time:)

[Aaron Harrison]

Hi

Well - basically an integer in SQL is an integer in UCCX - and it can contain a number. If you try to read a string into it it will get very upset, as you can't cast alpha characters into it (though you could cast a string of numbers into an integer).

A char field in SQL is a string in UCCX. If you try and cast an integer to a string that would be fine.

Unless you need to do mathsy things on the CSQ names (which are purely represented as numbers in your case) you would use a string/char to store CSQ names, as they aren't guaranteed to be numerical. You may add a CSQ with a text name at some point.

If you are retrieving a char (SQL) to a string (UCCX) and it works for some numbers but not others, there's probably a problem with your script logic in the next few steps.

Sounds like you have it working though?

Aaron