This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
integration:rdbms:sqlserver:updates [2011/04/12 16:29] doc |
integration:rdbms:sqlserver:updates [2016/06/28 22:38] (current) |
||
|---|---|---|---|
| Line 27: | Line 27: | ||
| Given these restrictions, most Omnidex applications refresh the data at regular intervals such as daily, weekly, or monthly. Once the data is refreshed, the indexes are rebuilt, producing an indexed version of the new data. This data can then be deployed into production. | Given these restrictions, most Omnidex applications refresh the data at regular intervals such as daily, weekly, or monthly. Once the data is refreshed, the indexes are rebuilt, producing an indexed version of the new data. This data can then be deployed into production. | ||
| - | For applications that require online updates, applications can use INSERT, DELETE, and UPDATE statements to update the table. This approach immediately updates both the database and the Omnidex indexes. | + | For applications that require online updates, applications can use INSERT, DELETE, and UPDATE statements to update the table. This approach immediately updates both the database and the Omnidex indexes. Alternatively, Omnidex allows SQL Server triggers to be installed on a table that copies changes to a separate transaction table. The [[programs:odxaim:home|OdxAIM program]] can generate SQL Server triggers for tables with Omnidex indexes. These SQL Server triggers log the changes to the data in a separate, intermediate transaction table, and then OdxAIM processes this transaction table in the background to update the Omnidex indexes. This approach preserves transactional integrity, though there is a short delay between the updates of the database and the indexes. |