FairCom has implemented the ability to "auto import" a table into SQL at the time it is accessed. This feature requires the user to provide a SQL callback library (ctsqlcbk) implementing the following:
The function prototype is:
CTDBRET ctsqlImpSetOptsCallbackFunc (pCTDBSESSION pSession, pTEXT dbname, pTEXT tblowner, pTEXT tblname, CTSQLIMPOPTS **opts);
The SQL server engine at startup loads the ctsqlcbk and makes a call to ctsqlCallbackLoaded passing type == 2 and registering the function returned in ptr.
At runtime, when the SQL parser encounters an object not present as a table in the system tables, if the registered function is not NULL and the user has resource permission or DBA permission when the table owner is someone else, the code calls the registered function and if the function returns CTDBRET_OK and sets the *opts != NULL attempts an automatic sqlimport using the opts returned overwriting the ignored members listed above as necessary for an internal server automatic sqlimport.
The "import" occurs in its own independent transaction (it cannot be reverted by rolling back the transaction). If the import fails for any reason, SQL statement execution continues as if the table simply does not exist.
After running the SQL callback function, a function is called to signal the memory allocated for opts should be released as follows:
ctsqlImpSetOptsCallbackFunc (pSession, NULL, NULL, NULL, opts).
The FairCom DB SQL Auto Import now supports an "Auto Import" callback. When this new callback has been registered, the server should adjust the dictionary in the system tables to remove info for tables that are no longer on disk. The idea being we will constantly update our dictionary to match the files present on disk that have been opened. This means c-tree will automatically purge the information out of the system tables for tables that were previously auto imported but are now missing on disk, and add information for tables (Auto Import) that are opened but were not in the dictionary.
When a table is not found on disk where it was when added to the system table, it is purged and the error -20005 is sent back to the application. No attempt is made to try to see if the table can be imported again.