External Db Error

[Guest Jonah]

I am using the latest version of VG (7.0.6). I added the following line of code into the VG.INI file

 

[VGDialer]

 

OutDialQue_ODBC_ConnectString=Driver={SQL Native Client};Server=rmsupmsql002\TEST,2222;Database=OutDialQue;Uid=ivruser;Pwd=Kpivr123;

 

When I add a record I can see the line status says "Sending Fax Calling Tone" (See Screenshot1) - and when I answer it does not run the script.

 

I have the same problem if I use the Dial List Loader application. (See Screenshot2)

 

This was working correctly in the previous version (7.0.5).

 

If I take out this line of code and restart the service, then the Dial List Loader works correctly. However, I need to use the SQL Server 2005 DB.

 

See Attached Log Files.

 

Screenshot1.doc

Screenshot2.doc

0923_ktTts.zip

[SupportTeam]

The external OutDialQue database format did change. This is what is probably affecting the outbound call here, with VoiceGuide thinking that you want to send a fax on the outbound call.

If you are using an external outbound calls source then the best thing to do would be for you to download the latest v7.0.7 release candidate: [old link removed]

After installing it please read the instructions in that version's Help file on setting up the external database. VoiceGuide v7.0.7 sets it up automatically after being given the connection string in the Config.xml file.

You are using SQL Server as your external source, correct?

[SupportTeam]

Was jus advised that with these pre-release v7.0.7 versions when the database is first created by VoiceGuide service it cannot be accessed by other programs immediately as it was created in read-only mode. Restarting the VoiceGuide service opens the now existing database in shared mode so you can now load calls into it using the Telephone Number Loader etc.

 

This will be fixed in next release but for now please just restart the VoiceGuide service after the first installation to enable the outbound calls being loaded into it.

[Guest Jonah]

I tried that but I must be missing a INI entry or something because the database was never even created. I know that the connection string works because it is the same one I used in version 7.0.5

[SupportTeam]

Have you looked at the Help file which ships with that version?

 

In the new version the connect strings etc. are not read from the VG.INI file.

 

The connect string would also be different.

[Guest Jonah]

I did read it - it's a bit vague. Here is my Dialer section as well as the logs. From reading the logs it looks as though its not even reading from the config file - but let me know if there is something obvious that I am missing.

 

P.S. Theis connect string did work in 7.0.5 when I put it in the VG.INI file.

 

<Dialer>

 

<Notes>

 

VistaDB.NET20:

Data Source='" + sDbOutDialQue_Fname + "';Open Mode=NonexclusiveReadWrite

Data Source='" + sDbFileName + "'"; //; LCID=1033; Password=\"s$;2'!dS64\"; Encrypt = TRUE;

 

MySQL:

Prefix: SELECT

Suffix: LIMIT 1

ODBC connect string:

{MySQL ODBC 3.51 Driver};Server=10.1.1.8;Port=3306;Database=OutDialQue;User=voiceguide;Password=v

iceguide;Option=3;

 

 

</Notes>

 

<OutDialQue_ADODB_Provider>SQLNCLI10</OutDialQue_ADODB_Provider>

<OutDialQue_Database>OutDialQue</OutDialQue_Database>

<OutDialQue_ConnectString>OutDialQue_ODBC_ConnectString=Driver={SQL Native Client};Server=rmsupmsql002\TEST,2222;Database=OutDialQue;Uid=ivruser;Pwd=Kpivr123;</OutDialQue_ConnectString>

<OutDialQue_SqlPrefix></OutDialQue_SqlPrefix>

<OutDialQue_SqlSuffix></OutDialQue_SqlSuffix>

</Dialer>

0924_ktTts.zip

[Guest Jonah]

I changed a couple things in the config file - still no luck. But here is what I have now.

 

<OutDialQue_ADODB_Provider>SQLOLEDB</OutDialQue_ADODB_Provider>

<OutDialQue_Database>OutDialQue</OutDialQue_Database>

<OutDialQue_ConnectString>Driver={SQL Native Client};Server=rmsupmsql002\TEST,2222;Database=OutDialQue;Uid=ivruser;Pwd=Kpivr123;</OutDialQue_ConnectString>

 

 

Also, I tried creating the DB with "Db_Create.sql". It created successfully but it's still not reading from it. I also tried the Call Loader App which did not load anything into the DB either. I am posting my latest logs as well.

0924_ktTts.zip

[SupportTeam]

If you are using SQL Server as your external Dialer database then have a look a the example provided in the Help file of the VoiceGuide version that is on your system There is an example there that shows the config for MS SQL Server 2008. Config for SQL Server 2005 will be very similar.

 

Just looking at your current Config.xml setup your <OutDialQue_ADODB_Provider> setting is wrong. You should also look at the connect string. As said above - read the Help file and see the MS SQL Server 2008 example there.

 

To test stop the VoiceGuide Service and just use the Telephone Number Loader. When you can load calls into the database and the Telephone Number Loader displays them in the list then you have it working.

[Guest Jonah]

Got it working! Thank you.

 

P.S. -- since I'm sure that I am a guini pig on this a suggestion may be that you display the DB errors to the user. My issue was that the user did not have appropriate write/create priveleges

[Guest Jonah]

It created the DB successfully and call loader does trigger calls, however.....

 

It still says "Sending Fax Calling Tone" and when I answer it does not play the script. I will attach screenshots and logs.

Screenshot1.doc

0925_ktTts.zip

[Guest Jonah]

I dont really understand the addition of the PortToUse table. In my opinion this unnessesarily overcomplicates the process. Now instead of just maintaining 1 table, I need to maintain 2. Also, everything but port number is redundant. Which table is it actually reading these values from? Also, why do I need to enter the GUID when there is already a CallID (uniqueID) field? It will not let me enter a row without this - also how do I generate it??

 

I think the old way worked just fine - just 1 field that contains the ports. Will this structure change? I will need to completely rewrite my outdial table pulls to accomodate this new structure and just want to make sure that the next release wont break it.

[SupportTeam]

There is no need to use the GUID if you link up the rows using the ID field.

 

GUID is just another way that lets you relate the rows in the two tables. GUID is used if you do not want to do a "SELECT @@identity" after inserting new row into the main table. You'd create the GUID and insert that in the related rows, and just place -1 in the CallID column of the PortToUse row(s).

 

If you do not want to use a GUID then after inserting the main row you'd need to find out the ID of the just inserted row (Usually use a SELECT @@identity command to do this) and then use that value in the CallID field in the PortToUse tables.

 

The tables were split into two to allow better performance on larger systems (100+ ports) with large number of calls (100,000+) that also want to send various calls out on specific ports (eg. for Least Cost Routing (LCR) purposes).

 

This table structure should stay the same in next release, but we may allow optionally to not use the PortToUse table if on your system the outgoing calls are allowed to be made on any of the system's lines. That is why the main table still contains all the call scheduling information.