It sounds like you're stuck letting these users go to town on ODBC - ouch, glad I don't have to support that! If they are developing, hopefully you have them going against a test environment that can be restarted without impacting your LIVE users.
If this is going on in LIVE, there was a solution out here a while back about how to put users on a separate server (if not here, then Epicor can provide it). So if you have an Epicor9ODBCUser app server you can just stop / start that one and they only take out their own group.
IMHO - ODBC connections should only be done via read only SQL views (replicated server if you're progress). The people writing those views should be knowledgeable enough about indexes, joining, proper data to use, etc. I had a report here that a user would kick off Friday night before leaving so she had the data Monday morning, took about 20 hours to run. I put in the proper joining, used grouping on the server and she was able to run it interactively. Just because people can get a report out of the system doesn't mean it's efficient...
[Non-text portions of this message have been removed]
If this is going on in LIVE, there was a solution out here a while back about how to put users on a separate server (if not here, then Epicor can provide it). So if you have an Epicor9ODBCUser app server you can just stop / start that one and they only take out their own group.
IMHO - ODBC connections should only be done via read only SQL views (replicated server if you're progress). The people writing those views should be knowledgeable enough about indexes, joining, proper data to use, etc. I had a report here that a user would kick off Friday night before leaving so she had the data Monday morning, took about 20 hours to run. I put in the proper joining, used grouping on the server and she was able to run it interactively. Just because people can get a report out of the system doesn't mean it's efficient...
[Non-text portions of this message have been removed]