Greetings. 

I am trying to use an indexed view in SQL Server 2000.  I created the view
and applied the index in Query Analyzer with appropriate ANSI settings i.e.
ARITHABORT, QUOTED_IDENTIFIER and ANSI_NULLS set to on (others were set as
well per SQL BOL).  Settings were made in SQL Query Analyzer window before
executing the create statement. 

Additionally, I have applied those same settings to a SQLQA window and
recreated various stored procedures...in some cases including repeating the
settings in those stored procedures. 

There are two scenarios which are pretty uncanny. 
Scenario one - which I am dealing with now - is that we have a stored proc
that loads and removes records from the two tables that the indexed view is
built upon, but do not directly touch the indexed view itself (its all
implicitly done by SQL Server).  In this scenario, I first tried using the
original procedure and inconsistently received invalid settings for the
ANSI_NULLS, QUOTED_IDENTIFIER and ARITHABORT.  I dropped and recreated the SP
with those three settings turned on in SQLQA (I also explicity state those
within the SP) and eliminated the ANSI_NULLS and QUOTED_IDENTIFIER errors,
but still get error on ARITHABORT setting when executed through an
application using ODBC (where ARITHABORT is set off by default)...though, I'd
understand that the setting in the proc itself should override the ODBC
setting.  My question is where else would this need to be set?  Should I have
the developer send "SET ARITHABORT ON" through ODBC?

Second scenario:  Multiple stored procs selecting from the indexed view. 
Also getting ARITHABORT error when executed through ODBC.  The developer,
using some Hyperion reporting tool, says there is no where he could find to
send a "SET" command from the application.  Funny thing is that I was able to
workaround these by dumping my result sets (within stored procedure) into a
#tmp table and retrieve from that #tmp table through the application without
the error.  Remove the #tmp table and the ARITHABORT error returns.  Does
anyone understand this behavior?

It's become frustrating using an indexed view because of this
"unpredictable" behavior.

Thanks for helping.

Tempdb is growing and I can't tell what process is to blame
Beating a dead horse - Drop table from proc
Stored Procedure (Weird Question)
Can I do this?
How to get the 4th record and on from select query