Outdial - Call Order (last In, First Out)

[michaeldallas]

The Autodialer module appears to dial the numbers as "last-in, first-out" (LIFO) order from the Access database (outdialque.mdb). (e.g. The last record added to the outdialque.mdb is dialed first. The second to last record added to the outdialque.mdb is dialed second. Etc.)

 

If my observation is true, this LIFO order will severely disrupt my application which adds records into the que in an (ongoing) prescribed dial order.

 

Question 1: Is my finding correct?

 

Question 2: If this is correct, how can this be changed other than continually deleting the records out of the database and then adding them back?

 

Michael Dallas

[SupportTeam]

Looks like you are adding records to be dialed at a rate faster then they can be dialed.

 

Currently if there are a number of calls ready to be dialed in the outdial database then in the absence of any indication of what order the queued calls are to be made VG will just dial whatever entry the database supplies it first. LIFO order is not explicitly stipulated - it just looks like the database ends up reporting last added record as the first matching record it can find when asked for 'what number should be dialed next'

 

Currently you can place the entries you add to be 'in order' - just use the Priority setting - and increment that setting by 1 (higher value means lower priority) for each subsequent entry you add.

 

We have now added an additional specific FIFO rule to apply in situations where more then 1 eligible numbers can be dialed. v5.2.3 onwards will have the FIFO functionality.

[michaeldallas]

Are there any limitations on the Priority field range. Since the datatype on Priority is Integer, I would assume the range is –32,768 to 32,767. Is that correct or are there other limitations within the Autodialer?

[SupportTeam]

The integer is at least a 'long' value - so the range is at least between -2 million and +2 million.

(could even be a 'double word' value...)

[michaeldallas]

You are incorrect about the integer limits (i.e. limits of the Priority field).

 

After reprogramming the xml file to deliver the Priority integers, I found that the maximum integer (priority value) in the priority.callque.outdialque.mdb was 9 - even though higher values were being delivered by the xml. (In other words, if I delivered the value of 12 (<Priority>12</Priority>), the database record showed a value in the Priority field of 9 instead.)

 

I then reset the vg.ini file's value "Prioritylevels=9" to higher numerical values. Any value placed in the setting over the integer limit (Prioritylevels=32,767) returns an "overflow" error.

 

Luckily, the value of 32,767 is high enough for now.

[SupportTeam]

I stand corrected. After closer investigation the current setting is indeed just a short integer. Changes to this have been made now and v5.2.3 onwards will allow a 'long integer' value to be used.

 

Also, the Prioritylevels VG.INI setting will in v5.2.3 onwards no longer limit the value of priority when loading the numbers to be called via XML input file.