We will now modify the project scheduling model, PERT introduced in Using Sets, to demonstrate the use of @ODBC to import the set names of the project's tasks from a Microsoft Access database. The modified model appears below, with changes listed in bold type:

SETS:

  TASKS: TIME, ES, LS, SLACK;

  PRED( TASKS, TASKS);

ENDSETS

 

DATA:

  TASKS = @ODBC( 'PERTODBC', 'TASKS', 'TASKS');

  PRED = @ODBC( 'PERTODBC', 'PRECEDENCE',

   'BEFORE', 'AFTER');

  TIME = @ODBC( 'PERTODBC');

ENDDATA

 

@FOR( TASKS( J)| J #GT# 1:

ES( J) = @MAX( PRED( I, J): ES( I) + TIME( I))

);

 

@FOR( TASKS( I)| I #LT# LTASK:

LS( I) = @MIN( PRED( I, J): LS( J) - TIME( I));

);

 

@FOR( TASKS( I): SLACK( I) = LS( I) - ES( I));

 

ES( 1) = 0;

LTASK = @SIZE( TASKS);

LS( LTASK) = ES( LTASK);

Model: PERTODBC

With the statement:

TASKS = @ODBC( 'PERTODBC', 'TASKS', 'TASKS');

we now fetch the members of the TASKS set from our ODBC data source, as opposed to explicitly listing them in the model. Specifically, we get the members of the TASKS set from the data column, or field, TASKS contained in the table named TASKS from the ODBC data source PERTODBC. Here is the data table as it appears in Access:

Access Database: PERTODBC.MDB

Next, we use the statement:

PRED = @ODBC( 'PERTODBC', 'PRECEDENCE',

   'BEFORE', 'AFTER');

to fetch the members of the PRED set from an ODBC data source, as opposed to explicitly listing them in the model. More specifically, we pull the members of the PRED set from the data columns BEFORE and AFTER contained in the table named PRECEDENCE from the ODBC data source PERTODBC. Here is the data table showing the precedence relations as it appears in Access:

Access Database: PERTODBC.MDB

Note that the set PRECEDENCE is a two-dimensional set. Thus, we must supply two database columns containing the set members.

In order to retrieve the values for the task times, we create the ODBC link:

TIME = @ODBC( 'PERTODBC');

Note that we only specified the ODBC data source name—the table and column names have been omitted. In which case, LINGO supplies default values for the table and column. The object being initialized, TIME, is a set attribute. Thus, LINGO supplies its parent set name, TASKS, as the default table name. For the default column name, LINGO supplies the set attribute’s name, TIME. Had we wanted to be specific, however, we could have explicitly entered all arguments to @ODBC with:

TIME = @ODBC( 'PERTODBC', 'TASKS', 'TIME');