To import a model’s data from an ODBC data source, we use the @ODBC function in the model’s data section. @ODBC allows us to import both text formatted set members and numerical set attribute values.

The syntax for using @ODBC to import data inside a data section is:

object_list = @ODBC(  [‘data_source’[, ‘table_name’

  [,’column_name_1’[, ‘column_name_2’ …]]]]);

The object_list is a list, optionally separated by commas, containing model objects (i.e., attributes, sets, or variables) that are to be initialized from the ODBC data source. Object_list may contain up to one set and/or multiple set attributes. All set attributes in object_list must be defined on the same set. If object_list contains a set, then all attributes in object_list must be defined on this set. The data_source argument is the name of the ODBC data source that contains the data table. The table_name argument is the name of the data table within the data source that contains the data. Finally, the column_name arguments are the names of the columns, or fields, in the data table table_name to retrieve the initialization data from. Set attributes and primitive sets require one column name each to retrieve their data from. Derived sets require one column name for each dimension of the set. Thus, a two-dimensional derived set would require two columns of data to initialize its members.

If the data_source argument is omitted, the model's title is used in its place (see the discussion of the TITLE statement). If table_name is omitted, the name of any set in the object_list is used in its place. If there is no set in object_list, then the name of the set that the attributes in object_list are defined on is used.

If the column_name arguments are omitted, LINGO will choose default names based on whether the corresponding object in object_list is a set attribute, a primitive set, or a derived set. When the object to be initialized is a set attribute or a primitive set, LINGO will use the name of the object as the default column name. When the object is a derived set, LINGO will generate one default column name for each dimension of the derived set, with each name being the same as the parent set that the given dimension is derived from. As an example, a two-dimensional set named LINKS derived from the two primitive sets SOURCE and DESTINATION would default to being initialized from the two columns titled SOURCE and DESTINATION.

Keep in mind that LINGO expects to find set members in text format in the database, while set attributes are expected to be in numeric format.

Some examples of using @ODBC to import data in a model's data section are:

Example 1:        SHIPPING_COST =

@ODBC( 'TRANSPORTATION',

 'LINKS','COST');

LINGO initializes the attribute SHIPPING_COST from the column COST contained in the data table LINKS found in the ODBC data source TRANSPORTATION.

Example 2:        VOLUME, WEIGHT =

  @ODBC( 'TRUCKS', 'CAPACITY');

The database column names are omitted, so, assuming VOLUME and WEIGHT are set attributes, LINGO defaults to using the attribute names (VOLUME and WEIGHT) as the database column names. Therefore, LINGO initializes the attributes VOLUME and WEIGHT from the columns also titled VOLUME and WEIGHT contained in the data table named CAPACITY found in the ODBC data source TRUCKS.

Example 3:        REQUIRED, DAYS = @ODBC();

In this example, we will assume a) we have titled the model PRODUCTION, b) REQUIRED is a derived set derived from the two primitive sets JOB and WORKSTATION ( e.g., REQUIRED( JOB, WORKSTATION)), and c) DAYS is a set attribute defined on the set REQUIRED. All arguments to the @ODBC function have been omitted, so LINGO supplies PRODUCTION as the data source name; the set name REQUIRED as the data table name; and the three data column names JOB, WORKSTATION, and DAYS. Had we wanted to be more specific, we could have explicitly included all the arguments to the @ODBC function with the equivalent statement:

REQUIRED, DAYS = @ODBC( 'PRODUCTION', 'JOB',

  'WORKSTATION', 'DAYS');