Domino Code Fragment
Code Name* @DbColumn(ODBC) | Date* 04/28/2024 | Source (or email address if you prefer)* Rlatulippe@romac.com IP address:.3.142.53.68 | |
Description* | Type* Formula | Categories* (Misc) |
Implementation: | Required Client: | Server: |
Limitations: | Comments: @DbColumn can only retrieve data; it can't add, delete, or modify data @DbColumn is intended mainly for keyword formulas. Instead of hardcoding a list of keywords and then periodically updating that list, @DbColumn lets you dynamically retrieve a list of values from an external database table. |
Parameters
"ODBC"
If you omit NoCache, you do not have to replace it with anythingthe lookup results are cached automatically, but you may specify "Cache" for readability.
For example, if youre using lookups to a database that stores customer addresses, its generally safe to use caching because you dont expect the addresses to change very often. But if youre using a lookup to a database where stock prices are stored, and that database gets updated hourly, its safer to omit caching and force a new lookup each time.
@DbLookup can access data sources that have already been registered in the ODBC.INI file (or similar registry on platforms on other than Windows). It can also autoregister a data source not present in the registry. For autoregistration, specify the data source as "data_source" : "type" : "path" where data_source is the name to be assigned, type identifies the DBMS (for example, "Oracle7"), and path is a server name, directory, or other string that locates the DBMS.
Specifying IDs and passwords
You only need these arguments if your DBMS requires them.
Instead of storing the IDs in the @DbColumn formula, you can replace them with null strings (""). If an ID is required, the user will be prompted for it. This is useful when you do not want other designers to see tDs, or when you want users to enter their own IDs when accessing external data. However, you must include IDs and passwords in formulas that run automatically (such as an agent) because these formulas don't prompt for information.
The user IDs and passwords for accessing a data source are required only once per Notes database session, as long as that database remains open. If the user opens another Notes database and executes a formula that accesses the same data source, the user ID and password will be required again.
Password parameters are necessary only when ID parameters are specified. Like the IDs, the passwords can either be stored in the @DbColumn formula, or prompted for by substituting the null string. If the database password is null, you can omit it from the formula.
For example, for the full ID/password specification, enter:
"dbo.author"
Table can also refer to a database view in the DBMS being accessed.
Specifying null handling
Normally, null values are ignored and the resulting list is shortened (same as using the Discard option described below).
To control how null values are handled, specify one of the following, appended to the column parameter with a colon:
If your formula includes a sort keyword, the list of values to be returned is sorted before the replacement values are inserted. During sorting, all null values are placed at the beginning of the list for an ascending sort; and at the end for a descending sort. They are not replaced until sorting is complete. This can result in a list that has some values sorted incorrectly. For example, if you specify "zz" as your replacement value, all the "zzz" values will appear at the beginning of the list, even if you sorted it in ascending order.
If one or more values are replaced when the @DbColumn formula is executed, Notes displays this message on the status bar:
Specifying sort
If you use the Distinct keyword, you can append the sort parameter to it with a colon. Use one these keywords for the sort parameter to specify sorting of the return values:
Note The sort keywords are not supported by all ODBC drivers. If you attempt to use both Ascending and Descending in your formula, Notes displays an "Invalid argument" message.
If multiple values are returned, they are formatted as a list and are separated with the multi-value separator designated for the current field.
@DbColumn can return no more than 55K bytes of data. Use the following equations to determine how much of your data can be returned with @DbColumn.
2 + (2 * number of entries returned) + total text size of all entries
Each text string is limited to 511 bytes; if only one text string is returned, it is limited to 55K bytes.
(10 * number of entries returned) + 6
NoExternalApps=1
the @DbColumn formula is disabled. The user will not see an error message; the formula fails to execute. This applies to @DbColumn only when you use it with ODBC.