Summary:ASTERISK-10433: need to change the SQL Query
Reporter:Private Name (falves11)Labels:
Date Opened:2007-10-02 14:41:30Date Closed:2011-06-07 14:03:09
Versions:Frequency of
Description:I need to change the query that is sent to SQL Server to look for a real time extension, to include the variable ${EXTEN} and also to remove the \ from '\_%' because SQL Server does not escape that character. In fact, the precise SQL Statement should be moved to *.conf file, because every SQL plataform is a little different.
I need to know how to access the variable ${EXTEN} at the place where this code is executed

if (!var) {
cfg = ast_load_realtime_multientry(table, "exten LIKE", "\\_%", "context", context, "priority", pri, NULL);
in pbx_realtime.c

The SQL Statement that hits SQL Server should look like:
SELECT * FROM extensions_table WHERE @p1 LIKE exten + '%'  AND context = @P2 AND priority >= @P3 ORDER BY priority

of course the variable @p1 should ve varchar(20) like the table column, not CHAR(3) and also the content of @P1 should be ${EXTEN}


Real time with SQL Server is not working and also it needs to send the incoming ${EXTEN} to the database so the matching can take place. I have 1.7 million extensions in my extensions_table, so I will return only the matching records, not the whole thing.

if somebody wants to see this in real life I have everything setup for development in a public IP address.
Comments:By: Tilghman Lesher (tilghman) 2007-10-03 08:52:41

You're not understanding how the code works.  If you have an exact match for an extension in the database, then the multientry code will not be called at all.  If, on the other hand, you have pattern matches, ALL of the pattern matches should be prefixed with an '_', to indicate a pattern match.

Realtime extensions uses EXACTLY the same pattern matches as in extensions.conf.  It is intended to be used as a direct translation from flat file media to database media.

If you have your data in a different format, then realtime extensions are entirely inappropriate for you to use.  In that case, I'd encourage you to look at func_odbc, as it is likely that you will find that to be far easier to adapt to your data.