Question : Native Error code: 414  - key size of 765 for a work table. This exceeds the maximum allowable limit of 600.

I have a stored procedure querying a Sybase database. The SQL is :
SELECT      tblLDAP.UserAutoId, tblLDAP.FirstName, tblLDAP.LastName
FROM      (tblContacts INNER JOIN tblLDAP       ON tblContacts.UserId = tblLDAP.UserAutoId)
INNER JOIN LDAP_CAD_Buildings       ON tblLDAP.Building = LDAP_CAD_Buildings.Building
WHERE LDAP_CAD_Buildings.Arena_id = @strRegion
GROUP BY      tblLDAP.UserAutoId, tblLDAP.FirstName, tblLDAP.LastName
ORDER BY      tblLDAP.LastName

Just recently it is generating the following error:
Sybase ADO Provider error '80004005'
[Native Error code: 414] [DataDirect ADO Sybase Provider] The current query would generate a key size of 765 for a work table. This exceeds the maximum allowable limit of 600.

The query works in a blink in both SQL Server and Access, but not in Sybase. All that has changed recently is that there has been an increase in records in the table tblLDAP from 32,000 records to 72,000. This would not have affected the output of the recordset which is dependant on tblContacts. tblContacts holds 534 records and LDAP_CAD_Buildings has 256 records.

The SQL produces a recordset of only 60 records
If I remove the aggregation the procedure will work.

What is causing this problem in Sybase and how do I correct it?

Answer : Native Error code: 414  - key size of 765 for a work table. This exceeds the maximum allowable limit of 600.

On its own, sadly no, that doesn't help much, as it doesn't tell us which worktable is unhappy about a key size. On the other hand if you were able to replicate your earlier experience (with smaller rowcounts) and get a SHOWPLAN from that, it could be helpful to compare the differences.

Did any indexes change recently?

I notice the showplan saying it used a covered non-clustered index. This might be a large index containing other columns not needed for this query, and the limit might be too large.

Oh, I just thought of another reason for why this might have changed - if these columns are varchars, it might be that their maximum width exceeds the 600 byte limitation, but you were never affected by this earlier because none of your columns were filling up the varchars. Can we get some more information, the results of:

sp_help tblLDAP
go
select max(datalength(UserAutoId)),
          max(datalength(FirstName)),
          max(datalength(LastName))
from   tblLDAP
go

(It will table scan, sorry.)

It could be that one or more of the new rows causes the GROUP BY expression to be too large.

Lastly, try removing the GROUP BY altogether and replacing it with a DISTINCT:

SELECT     DISTINCT tblLDAP.UserAutoId, tblLDAP.FirstName, tblLDAP.LastName
FROM     (tblContacts INNER JOIN tblLDAP      ON tblContacts.UserId = tblLDAP.UserAutoId)
INNER JOIN LDAP_CAD_Buildings      ON tblLDAP.Building = LDAP_CAD_Buildings.Building
WHERE LDAP_CAD_Buildings.Arena_id = @strRegion
ORDER BY     tblLDAP.LastName

It doesn't seem you're using the GROUP BY for any aggregate functions, so all it will be doing is removing duplicates. Speaking of which, a column name like "UserAutoId" sounds like it would probably be unique - are you sure any duplicates are possible in this query? If not, then neither a GROUP BY nor a DISTINCT are needed here...

Good luck!