Pitney Bowes MapXtreme - Manual (Page 174)

Chapter 8: Working with Data
Table Metadata (TableInfo)
MapXtreme v7.1 181 Developer Guide
1. In the MapInfo.WebControls.StateManager.SaveState method:
a. Place the ADO.NET DataTable or DataSet into the HTTPSession instance.
b. Save any MapInfo.Data.TableInfoView or MapInfo.Data.TableInfoResultSet tables that are
dependent on the ADO.NET table using the
ManualSerializer.SaveMapXtremeObjectIntoHttpSession.
c. Close the ADO.NET table in the Catalog.
2. In the MapInfo.WebControls.StateManager.RestoreState method:
a. Create a new TableInfoAdoNet object based on the DataTable retrieved from the
HTTPSession instance.
b. Open a new ADO.NET table in the catalog based on the TableInfoAdoNet object with the
same name as the original.
c. Restore any MapInfo.Data.TableInfoView or MapInfo.Data.TableInfoResultSet tables based
on the ADO.NET table using ManualSerializer.RestoreMapXtremeObjectFromHttpSession.
It is important to remember that the order you save and restore is critical to the proper creation of all
the tables and their dependencies. For more information on serialization, see
Chapter 6:
Understanding State Management .
Accessing Data Using an IDbCommand
The second form of ADO.NET table is based on the connected object types in ADO.NET:
Connection, Command, and DataReader. MapInfo Tables constructed in this fashion are read-only.
These types of tables are created by passing to the Catalog an IDbCommand object that is already
configured to return all of the data that is to comprise the table. When the table is initially created (by
calling Catalog.OpenTable), ExecuteReader is called on the IDbCommand. The resulting data
reader is used to determine the columns and their data types. All subsequent cursor requests (other
than cursors which retrieve a specific record - called a key fetch) also call ExecuteReader to fetch
the data to satisfy the cursor. Notice that this may be very inefficient. If at all possible, use one of the
other table types to access your data.
Since the Command-based form of the ADO.NET table is designed to use the generic interfaces
without requiring any specific knowledge of any particular implementation of these interfaces, the
table also does not assume that the IDbCommand.CommandText is any form of standard SQL. In
fact, it may not be SQL at all. This table type does not access, parse, or modify the CommandText.
This means that this table type has no mechanism for knowing which column(s) in the results
formulate a unique, non-null key value. For this type of table, it is required to tell the table which
column(s) constitute the key. This is accomplished by specifying the KeyType as Explicit and setting
the KeyColumns property.
There are many operations inside the MapInfo Data Provider which require the retrieval of a specific
record by key (also referred to as a key fetch). Select statements with a where clause of the form
MI_Key = '5' is a simple example in which we need to retrieve the record whose MI_Key column can
be represented by the string literal '5'. Key retrievals are very common in mapping selections,
labeling, and scrolling in a MIScrollableReader (in which case the reader may be scrolling through a
list of key values). MapInfo tables are dependent upon the ability to efficiently fetch records by key
value. Just as the Command-based form of the ADO.NET table does not read, parse, or modify the
CommandText of the IDbCommand object that defines the table (the “Sequential” IDbCommand), it