deko wrote:
--In the Index Properties section (bottom) of the
dialog, Select "Yes" for Primary
But I already have Primary Key - the AutoNumber field that's the ID for the
table. That's the issue. I need a composite unique index to prevent dupe
transactions (same amount, same date, same account, same customerID), but
want a single field for a PK. What I described above seems to do the
trick - but a new question arises.
What about the CustomerID field - which is a Foreign Key? Should that have
another index applied separately? Also the date and account fields are used
extensively for searching - should those each have a separate index applied
as well? I assume the answer is yes. This makes for a heavily indexed
table, but AFAIK there is no problem with that.
What is a primary key other than a unique index (not null) which the
dbengine uses as its primary (first) organizer? Can there be other
unique indexes, on one or more fields? Sure, there can.
The notion of "primary key" is neither sacred nor mysterious. I think it
might better be called the "default (unique) index".
"How many indexes?" is another question. There is a trade-off between
indexes and their uses, and the overhead that indexing requires. I have
read that in MS-SQL a primary key is the data. This puzzles me on one
hand, but seems entirely logical on the other, if an autonumber identity
column is the primary key.
You, as db designer, must decide where and when the advantages of
indexing out weigh the disadvantages.
I liked (maybe still do) older database engines where indexes were
external files, and could be applied or not applied, updated or not
updated, all-inclusive or subsets (index on lastname where
municipality='A mboy'), based on columns, functions or even columns in
other tables, or a combination there-of. Yes, you had to manage them
yourself, but this was OK with me.
--
--
Lyle
--
From ADO28.chm
Deprecated Components
Each of the following components is considered obsolete. While these
components are still supported in this release of the Microsoft® Data
Access Components (MDAC), they may be removed in the future. When
writing new applications, you should avoid using these deprecated
components. When modifying existing applications, you are strongly
encouraged to remove any dependency on these components.
ODBC Provider (MSDASQL)
You are strongly encouraged to use one of the native OLE DB Providers
instead of the Microsoft Open Database Connectivity (ODBC) Provider.
Native OLE DB Providers provide better application stability and
performance. Furthermore, native OLE DB Providers will be supported in
the future, whereas MSDASQL will not have any new features added to it,
will not be available on 64-bit, and will not be accessible from the OLE
DB NET Data Provider.
Remote Data Services (RDS)
Remote Data Services (RDS) is a proprietary Microsoft mechanism for
accessing remote data across the Internet or intranet. Microsoft is now
shipping the Microsoft Simple Object Access Protocol (SOAP) Toolkit 2.0
that enables you to access remote data using an open, XML-based
standard. Given the availability of the SOAP Toolkit 2.0, you should
migrate from RDS to SOAP. The SOAP 2.0 Toolkit 2.0 also includes sample
code for remotely accessing Microsoft ActiveX® Data Objects (ADO)
Recordsets.
Jet and Replication Objects (JRO)
The Microsoft Jet OLE DB Provider and other related components were
removed from MDAC 2.6. Microsoft has deprecated the Microsoft Jet
Engine, and plans no new releases or service packs for this component.
As a result, the Jet and Replication Objects (JRO) is being deprecated
in this release and will not be available in any future MDAC releases.
.....