An instance of GAMSDatabase communicates data between the .NET world and the GAMS world. A GAMSDatabase consists of a collection of symbols (GAMSDatabase implements the IEnumerable interface, that allows to iterate conveniently through the symbols in a GAMSDatabase). The symbol types available for a GAMSDatabase correspond to the symbols types know from the GAMS language: Set, Parameter, Variable, and Equation are represented in .NET by a derived class (e.g. GAMSSet, GAMSParameter, etc). Besides the type, a GAMSSymbol has a name (this has to match the name inside the GAMS model), a dimension (currently up to 20 or gamsglobals.maxdim) and some explanatory text.

Variables and equations also have a subtype: e.g. Binary, Positive, etc. for variables (see type gamsglobals.VarType) and e.g. E, G etc. for equations (see type gamsglobals.EquType).

GAMSDatabases can be created empty, or initialized from existing GDX files or from another GAMSDatabase (copy). Symbols can be added at any time (e.g. GAMSDatabase.AddParameter), but once a symbol is part of a GAMSDatabase, it cannot be removed. Only its associated data (GAMSSymbolRecord) can be purged (see GAMSSymbol.Clear()) or individually removed (GAMSSymbol.DeleteRecord). Individual data elements are accessed record by record. A record is identified by the keys (a vector of strings). The record data varies by symbol type. For example, a parameter record has a Value property, a variable has the properties Level, Lower, Upper, Marginal, and Scale. Adding a record with keys that already exist results in an exception. Similar, the unsuccessful search for a record also results in an exception.

GAMSSymbol implements the IEnumerable interface to conveniently iterate through the records of a symbol. There are also sliced access methods to symbol records that allow to iterate through all records with a fixed index at some positions. GAMSDatabases can be exported as GDX files for permanent storage. They also manage external resources and need to be properly disposed before the .NET garbage collector reclaims the instance.

GAMSJob (OutDB) and GAMSModelInstance (SyncDB) provide instances of GAMSDatabase to communicate results from a GAMS run or a solve. These databases should only be used in the context of the base object (GAMSJob or GAMSModelInstance). If a copy of such a database is required the GAMSDatabase constructor that initializes a GAMSDatabase from another database should be used (e.g. GAMSDatabase newdb = workspace.AddDatabase(GAMSJob.OutDB);).

GAMSDatabases often provide the input data for a GAMSJob. Such GAMSDatabases are listed in the GAMSJob.Run methods. Inside the GAMS model source the GAMSDatabase is accessible through a GDX file. The GAMS model source requires a particular file name to connect to the proper GDX file (e.g. $GDXIN filename). A GAMSDatabase can be created with a given name which can be then used inside the model (e.g. GAMSDatabase db = workspace.AddDatabase(databaseName:"SupplyData"); and then inside the GAMS model source: $GDXIN SupplyData) or an automatically generated name can be used. This name can be passed down to the GAMS model by using the Defines list of a GAMSOptions instance:

Inside the GAMS model source the name is accessed as follows:

One has to act with some caution when it comes to ordered sets which e.g. allow lag and lead. By not enforcing the "domain checking" for the GAMSDatabase .NET class we have aggravated the potential problems for ordered sets. For GAMS, the labels of set elements are just strings, so the order of a set is determined by the appearance of its elements. For example, if one has 'set k / 2,3,4,1,5 /', the order of k is exactly given by this sequence. So the lag (k-1) of k=4 is 3 and the lead (k+1) of k=4 is 1.

GAMS performs arithmetic with an extended number range. GAMS has special values for infinity (+INF, -INF), epsilon (EPS), not available (NA), and undefined (UNDEF). When GAMS evaluates expressions with these special values, the calculating engine ensures the correctness of the result (e.g. 5*eps=eps or 5+eps=5). The GAMS model CRAZY in the GAMS Model Library documents the results of the arithmetic operations with respect to special values.

In the GAMS .NET API we map the IEEE standard values for +/-infinity (e.g. double.PositiveInfinity) and NA (double.NaN) to the corresponding GAMS values. The special value for UNDEF gets unfiltered through the GAMS .NET API. The internal double value of UNDEF is 1.0E300 (or better use the constant sv_valund from gamsglobals).

Special attention needs to be given to the value of 0. Since GAMS is a sparse system it does not store (parameter) records with a true 0. If a record with numerical value of 0 is needed, EPS can help. For example:

will result in

but

will result in

What are the consequences for the GAMS .NET API? If we read parameter b in case of b('5')=0, the GAMSDatabase will not have a record for b('5'). In case of b('5')=EPS, the GAMSDatabase will have a record with value double.Epsilon. Unlike the IEEE values (e.g. double.PositivInfinity), arithmetic operations in .NET will modify double.Epsilon (e.g. 5*double.PositiveInfinity==double.PositiveInfinity but 5*double.Epsilon!=double.Epsilon). The same rules apply for preparing input data for GAMS in a GAMSDatabase. If a value of double.Epsilon is written, GAMS will see the special value EPS. The value used for EPS can be reset using the GAMSWorkspace property MyEPS. All other small values (including 0) will be communicated unfiltered to GAMS. As mentioned before, zeros will not be entered as data records in GAMS. The compiler control $on/offEPS can help to automatically map zeros to EPS.

There is one oddity concerning values smaller than 1e-250 on GAMS input. Consider the following example:

A record with values smaller than 1e-250 exists on input in GAMS, but as soon as the record gets updated by GAMS and is still smaller than 1e-250, the record gets removed.

The ordering of a set in GAMS can be non-intuitive: Consider "set i /5/, j /1*5/;". Elements '5' gets internal number 1, '1' get 2, '2' gets 3 and so on. The last element of j '5' has already the internal number 1. The sequence of internal numbers in j is not ascending and hence GAMS considers set j as not sorted, i.e. one can't use the ord() function nor the lag or lead (-,–,+,++) operators. If 'j' would have been defined before 'i' in this example, the "set not ordered" problem would have been avoided.

Please note that the GAMSDatabase actually does not implement a relational model for database management. It should be seen as a data storage or data container.