Data Access Worldwide Knowledge Base
Article Text
QUESTION:
I just want to make sure I understand how these work before recklessly abandoning all recnum references & support.
Beyond the initial setup of a table where you specify either "Recnum Support" or not, there doesn't seem to be any "visible" settings in the Database Builder that provide specific settings to non-recnum files. If you have a non-recnum table, how is the primary key
determined? There doesn't seem to be anywhere this is set beyond specifying DF_FILE_PRIMARY_INDEX. Is this always assumed to be 1 by default, or is there something else going on? Is the setting of this done in the DD file so that it's "permanent"?
In the doc for DF_FILE_PRIMARY_INDEX it states: "Most often these fields will be your primary key." What would be an example of the primary key NOT being defined by the setting of DF_FILE_PRIMARY_INDEX? I don't see any other settings that define this so if it's not defined by DF_FILE_PRIMARY_INDEX, what would control the primary key?
I also assume, but just want to make sure, that the primary key value has nothing to do with defining fields as "Key Fields" other than generally the fields you would specify as key fields tend to be the ones that comprise your primary unique index.
Any clarification on the above is appreciated.
ANSWER:
There is some confusion on this topic I will try to make it a bit clearer.
There are a number of Connectivity Kits that support standard (non-recnum) tables and there are Connectivity Kits that do not. You can only use standard tables if you are using one of the Connectivity Kits that support it. Standard tables are supported by the ODBC, DB2 and SQL Server CK version 4 or higher. All other CK (including the Embedded Database) do not support standard tables. If, for example, you use the SQL Server CK version 3.x, all tables accessed through this CK will be recnum tables.
If you use a standard table, a way to uniquely identify a record must be provided. The database API uses the RowID concept for this. How you exactly define a RowID depends on the CK used. The Data Access CKs use an attribute called DF_FILE_PRIMARY_INDEX for this. This holds the index number of the index that uniquely identifies a record. The index can have one or more segments of any type.
You can set up this attribute by checking the "Index is the primary index" chekbox on the index tab page. This checkbox is only available for ODBC, DB2 or SQL Server tables. If you do not see this checkbox, you are using a CK that does not support standard tables, or you
are using the Embedded Database that also does not support standard tables.
The databases accessed through the CKs that support standard tables usually support the Primary Key concept. In the table definition you can define a primary key. This is the primary key the documentation is referring to. You control this by using whatever database management software is delivered with your database. Although primary keys are supported, you are not required to define one for a table.
In those cases, there is no primary key and you will have to use one of the unque indexes for the table. If there are no unique indexes, you will not be able to connect to the table.
You could ask:
Isn't setting an embedded database to non-Recnum the equivalent of using it as a standard table, and therefore requiring that it would need a primary index defined and set? or the embedded database always uses recnum as the RowID, regardless of whether you've checked or un-checked Recnum support?
There are two concepts that we need to clarify: Table type and Programming style.
The table type can be recnum or standard table. The Embedded Database only supports recnum tables, every table you access is a recnum table. So yes, no matter how you checked recnum support you will have a recnum table.
In your programming style you can use RowIDs no matter what the table type is . In other words, you can use the RowID type, functions and procedures on recnum tables.
Contributed By:
Ben Weijers
Company: Data Access Worldwide
Web Site: http://www.dataaccess.com
Email this Article
Email this Article to a Colleague
Send Feedback on this Article to Data Access Worldwide
Copyright ©2010 Data Access Corporation. All rights reserved.
| The information provided in the Data Access Technical Knowledge Base is provided "as is" without warranty of any kind. Data Access Corporation disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Data Access Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Data Access Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply. |