Hi Simon,
Please always include the ASE version string when asking about a specific issue.
Not that I find it would help in this particular instance, but it often does help, so it is a very good practice to get into.
There isn't a lot to go on here, so it is very nice that you can reproduce it at will.
But there are a few clues. The stack itself is truncated, there would normally be a number of function calls below the kisignal(), which is what is called when ASE received the signal 11 from the OS.
So the only function/method call we have is in the header, the LeSQLRep::_sqlRepParamSet().
The "Rep" in the name suggests it has something to do with replication. Having access to the ASE source code, I can see that the method is largely concerned with finding a table name and has a large chunk dealing with fully qualified table names (database.owner.tablename).
I've also searched the bug database and don't find any known bugs involving this method call.
So the problem is seen when selecting into this user database, but not when doing it into
a temp db. Is the user database marked for replication?
I can't suggest any particular traceflags, etc., but an approach I often take at this point where I have a query that reliably generates a problem is to work on simplifying the query, whittling it down to the bare minimum that will reproduce the problem. I do this by commenting things out a few at a time, usually in about this order:
columns in the result set,
WHERE and HAVING clauses involving literal values
ORDER BY
HAVING
GROUP BY
TABLES and their JOIN clauses
If the problem still reproduces, I then delete what I had commented out before and comment out the next things, if the problem stops reproducing, I uncomment and go comment something else.
The resulting simplifed query is usually much smaller and often points pretty directly to the root cause.
Is MY_DB the same database that the other tables are in (the dump you received), or is it a newly created database?
