LeftForDead
20 pts. | Sep 18 2009 11:28AM GMT
I modified the stored procedure further, to try and isolate the problem, and I began with the simplest possibility - expecting it to succeed - but it failed at line 67…
print ‘——right before the select———–’
–2009
–Nov 14 2008 12:00AM
SELECT –line 67–
LTRIM(RTRIM(T_ASFSTAG0.STANS1)),
LTRIM(RTRIM(T_ASFSTAG0.STHFO1)), LTRIM(RTRIM(T_ASFSTAG0.STRSP1))
FROM T_ASFSTAG0
/* WHERE (T_ASFSTAG0.STANS1=@AnneeSelectionnee) AND
((isdate(T_ASFSTAG0.STCRT1)=1 and (convert(datetime,convert(varchar,T_ASFSTAG0.STCRT1))>=convert(datetime,convert(varchar,@DateDernierImport,103),103))) or
(isdate(T_ASFSTAG0.STMAJ1)=1 and (convert(datetime,convert(varchar,T_ASFSTAG0.STMAJ1))>=convert(datetime,convert(varchar,@DateDernierImport,103),103))))
*/print ‘——after the select and before the insert———–’
So it seems the view (in production for X number of years) or, most likely, the openquery is the culprit.
The view’s code:
SELECT STANS1, STSTA1–,… snip many others FROM OPENQUERY(ISERIES_SQLDBF, ‘SELECT * FROM tstadvdbf.ASFSTAG0′) AS DerivedTable1
Maybe it’s a question of resources - the only real difference between my VM test environment and the production server. Could it be that my VM can’t handle the resources this SELECT demands since it’s connecting, real time, to a linked server (AS400)?
Meandyou
1840 pts. | Sep 18 2009 3:25PM GMT
When I first your the question, my first thought was a missing terminator following the failing SQL statement, something between the SELECT and the PRINT statements. That is my only thought on this subject.






