13.01.2013 Views

OpenEdge Data Management: DataServer for Microsoft SQL Server

OpenEdge Data Management: DataServer for Microsoft SQL Server

OpenEdge Data Management: DataServer for Microsoft SQL Server

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

ABL issues<br />

• If you <strong>for</strong>ce the creation of a record be<strong>for</strong>e entering the value <strong>for</strong> the designated column<br />

(<strong>for</strong> example, by committing a transaction or releasing or validating a record), the creation<br />

fails if the column cannot have NULL values. If the column can have NULL values, the<br />

<strong>Data</strong><strong>Server</strong> assigns the new record a ROWID of NULL. However, if the column has an initial<br />

value, the <strong>Data</strong><strong>Server</strong> creates the row with that initial value as the ROWID.<br />

Follow these guidelines when using ROWID in applications that you want to deploy across<br />

multiple <strong>OpenEdge</strong> databases and/or MS <strong>SQL</strong> <strong>Server</strong> data sources:<br />

• Do not try to get a record’s ROWID value be<strong>for</strong>e the user assigns values to the unique keys<br />

of the record.<br />

• Refresh the ROWID value if a value of a unique key might have changed.<br />

Refresh the ROWID value after you undo a DELETE. The ROWID value might be different after<br />

the record is recreated.<br />

• ROWID values are stable <strong>for</strong> a session, but you cannot rely on them to be the same across<br />

sessions.<br />

Note: Reposition functions such as REPOSITION-BACKWARDS and REPOSITION-TO-ROW<br />

typically use ROWID to identify records. Functions of this type require integer<br />

expressions, which can be either INTEGER or INT64.<br />

For a complete description of the ROWID function, see its reference entry in <strong>OpenEdge</strong><br />

Development: ABL Reference.<br />

RECID function<br />

For backward compatibility, the <strong>Data</strong><strong>Server</strong> supports the RECID function <strong>for</strong> MS <strong>SQL</strong> <strong>Server</strong><br />

data source tables that have a unique 4-byte integer column defined as the key <strong>for</strong> the<br />

ROWID/RECID index of a given table in the schema holder. Whenever the ROWID index selection<br />

<strong>for</strong> a schema holder table in the Dictionary has multi-component key composite or is a<br />

single-component key but not a single unique integer component, the RECID function is not<br />

supported and the compiler will disallow the use of the RECID function in a WHERE clause.<br />

Note: The ROWID function does not have this same restriction and is the recommended<br />

alternative <strong>for</strong> this limitation.<br />

When the Create RECID Field option is selected, the <strong>OpenEdge</strong> DB to MS <strong>SQL</strong> <strong>Server</strong><br />

migration utility creates an indexed column with unique values <strong>for</strong> each row called<br />

PROGRESS_RECID. Starting with <strong>OpenEdge</strong> Release 10.1B, the field is defined as bigint and in<br />

Release 10.1A or earlier, the field is defined as integer. You can also add this column to tables<br />

manually if you are using an existing MS <strong>SQL</strong> <strong>Server</strong> database or if you ported an <strong>OpenEdge</strong><br />

database without the Create RECID Field option selected.<br />

If the PROGRESS_RECID field does not exist in the table, the <strong>Data</strong><strong>Server</strong> utility automatically<br />

designates the index that meets the unique key criteria. For a complete description of the RECID<br />

function, see its reference entry in <strong>OpenEdge</strong> Development: ABL Reference.<br />

2–53

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!