[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sas-l
Subject:    Re: ODBC index usage, SQL Server
From:       "David L. Cassell" <Cassell.David () EPAMAIL ! EPA ! GOV>
Date:       2001-02-28 21:42:01
[Download RAW message or body]

Frank DiIorio wrote [in part]:
> Well, no, there IS an index defined, but SAS doesn't see it.  I
> haven't located anything in the documentation that says you can't use
> a composite index for this data source.  Has anyone run into this?
> If so, is this just not possible, and if it isn't, is there a
> workaround?  One workaround I thought of was concatenating the fields
> that make up the composite index, then creating a simple index on
> that new, concatenated field.  Not appealing, but it'd work.  Any
> thoughts would be appreciated.

If the composite index were for a SAS data set, SAS would find it.  But I'm
guessing from your discussion that the composite index is built on the
SQL Server side and SAS isn't grokking it.  I haven't hit this problem
before outside of SAS data sets, but I can tell you that building a simple
index as the concatenation of multiple fields is a very workable solution.

You do have to be very careful about padding fields properly so the
variables
line up right for the desired sort order.  That is, left-align the
character
fields as is appropriate and pad on the right with blanks so the next field
gets lined up properly.  Or, when concatenating numbers, turn them into
strings and pad on the left with zeroes so they line up in sort order.

David
--
David Cassell, OAO Corp.                           Cassell.David@epa.gov
Senior computing specialist
mathematical statistician

[prev in list] [next in list] [prev in thread] [next in thread]