Domino Code Fragment

Code Name*
@DbLookup( ODBC)
Date*
04/29/2024
Source (or email address if you prefer)*
Rlatulippe@romac.com
IP address:.3.14.132.214
Description*
Given data source information from the ODBC.INI file, uses this information to activate the appropriate ODBC driver. The driver then locates the specified DBMS, table, and column, and returns only the values in that column belonging to records whose value in the key column matches the specified key. You can optionally specify whether the returned list of values is sorted, whether duplicate values are deleted, and how null values are handled.
Type*
Formula
Categories*
(Misc)
Implementation:
Required Client:
Server:
Limitations:
Comments:
@DbLookup can only retrieve data; it can't add, delete, or modify data. @DbLookup is intended mainly for keyword formulas. Instead of hard­coding a list of keywords and then periodically updating that list, @DbLookup lets you dynamically retrieve a list of values from an external database table. @DbLookup can't be used in mail macros, although it does work in paste macros.
Files/Graphics attachments (if applicable): Code:
@DbLookup( ODBC : NoCache ; data_source ; user_ID1 : user_ID2 ; "password1" : "password2" ; table ; column : null_handling ; key_column ; key ; Distinct : sort )

Parameters
"ODBC"


"NoCache"
"data_source"
"user_ID1" : "user_ID2"
"password1" : "password2"
"table"
"column"
"null_handling"
"key_column"
"key"
"Distinct"
"sort"
Return value
valuesFound
Specifying NoCache
The decision to use NoCache is based on performance. Forcing Notes to connect to the database and retrieve the same information again and again takes time, and slows overall performance. However, if you expect that data to be changing on a frequent basis, it's worth the extra time to get updated information.

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.


Specifying the data source
The data source name can contain up to 32 alphanumeric characters.

@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 @DbLookup 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 IDs, or when you want users to enter their own IDs when accessing external data. However, you must include IDs and passwords in formulas that will run automatically (such as an agent) because those 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 IDs, passwords can either be stored in the @DbLookup formula, or prompted for by the ODBC driver 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:


Specifying the table name
If the DBMS supports it, you can optionally include the name of the table's owner to remove ambiguity. Use the format "owner_name.table_name", with a period separating the owner name and the table name.

For example:

"dbo.author"

Table can also refer to a database view in the DBMS being accessed.

Specifying null handling
To control how null values are handled, specify one of the following, appended to the column parameter with a colon:


Null values found - @Db function
Caution: NULL values discarded from @Db list.
Caution: NULL value replaced with user-defined value in @Db list
Specifying key_column and key
Use key_column to indicate which column to search for the specified key; enclose the column name in quotation marks. If the DBMS product uses case­sensitive column names, be sure to use the correct capitalization. The values in the key column do not have to be sorted before you retrieve data with @DbLookup.

The key can be any value; if its a string (text) value, enclose it in quotation marks.

Together, the key column and the key form the where clause of a selection statement:

SELECT column WHERE key_column = key

The ODBC Application Interface always tests for equality and only returns data from records where the value in the key column exactly matches the key. To test whether the value in the key column matches one of several possible values, format the key value as a list, separating items with colons as in Red:Blue:Green." This acts like an OR operation, returning data from all records where the value in the key column matches Red OR Blue OR Green." To perform an AND operation or to test for inequality, use @DbCommand to pass the appropriate command string to the DBMS.

Specifying Distinct
The Distinct keyword is similar to @Unique in Notes, except that Distinct ensures that duplicate values are removed before the data is returned to Notes. Using Distinct instead of @Unique has two advantages:


Note Distinct is not supported by all ODBC drivers. If there are null values in the data and you specify Distinct, one null is usually returned.

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:


If no sort keyword is specified, values are returned in arbitrary order.

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.

Accessing values found

If multiple values are returned, they are formatted as a list and are separated with the multi-value separator designated for the current field.

@DbLookup can return no more than 55K bytes of data. Use the following equations to determine how much of your data can be returned with @DbLookup.


If the user's NOTES.INI file includes the statement:

NoExternalApps=1

the @DbLookup formula is disabled. The user will not see an error message; the formula fails to execute. This applies to @DbLookup only when you use it with ODBC.