I have created a little store procedure that goes as shown below. This
may not be graceful but it works, and this isn't the problem. The
problem is (and I will be cross posting this) that when I try to link
this stored proc into Crystal 8.5, I get a "Invalid file link. Field
is not indexed" error. I have also tried this by creating a PK and
get the same result.
The question: How do you return a result set from a stored procedure
that includes an index?
tia,
Steve.
CREATE PROCEDURE GetValidationValue (@.ValidationKey varchar(18))
AS
DECLARE @.ValidKey varchar(18)
SELECT @.ValidKey = @.ValidationKey
/* creating a table - so that we can return rows in the end */
CREATE TABLE #MyValidationValues
(
vlv_id varchar(18),
valid_id varchar(18),
valid_key varchar(18),
valid_value varchar(30),
vlv_desc varchar(50)
)
CREATE INDEX valid_key_ind
ON #MyValidationValues (valid_key)
INSERT INTO #MyValidationValues SELECT vlv_id, valid_id, valid_key,
valid_value, vlv_desc
FROM validation_values WHERE valid_key = @.ValidKey
SELECT * From #MyValidationValues
GO> this stored proc into Crystal 8.5, I get a "Invalid file link. Field
> is not indexed" error. I have also tried this by creating a PK and
This would appear to be an issue with Crystal. It may help to put "set
nocount on" as the first statement in the procedure. However, you should
not need that as your procedure should be as follows:
CREATE PROCEDURE GetValidationValue
@.ValidationKey varchar(18)
AS
SELECT vlv_id, valid_id, valid_key, valid_value, vlv_desc
FROM validation_values WHERE valid_key = @.ValidKey
ORDER BY valid_key_ind
GO
Everything else in your current procedure is not needed or wasteful.
Indexing a table serves no purpose if it is not used and your current
procedure does not "use" it. Perhaps you are assuming that the index
somehow forces the rows to be returned in a specific order within the
rowset. If so, don't. This is an invalid and unsafe assumption. BY
DEFINITION, a result set is unordered unless it includes an order by clause.
Many developers are now learning about this unsafe assumption due to changes
in sql server 2005.
Tuesday, February 21, 2012
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment