Hi.

I have the following sections and declarations in a 
template:

---
<TEDECLARE DBSOURCE name="theList" datasource="SSurfer" 
userid="SSurfer" password="tart">

<TEDECLARE DBSELECT
  name="LISTOPTIONS" dbsource="theList"
  SQL="SELECT * FROM tblListOptions WHERE fldListID=?I">

<TESECTION databasecheck
	WHEN TranPath_1 is "databasecheck">
<TEACTION CONNECT "LU_GROUP_1:NULL">
<TEFETCH select="LISTOPTIONS" 10>
<TEACTION RELEASE>
</TESECTION>
---

When you run the transaction, and then look at the trace in 
the dev centre, you can see that it has returned zero 
records - although it has successfully managed to find the 
fieldnames. It also says that it expected one parameter, 
that it had received one, and that the value was indeed 10.

However, if I remove the parameter option from the TEFETCH, 
and stick the value 10 directly into
 

If the process was working and stopped--there may be a 
version upgrade on one of these components that you don't 
know about.

Early versions of Windows/2000 had some ODBC bugs that drove 
us crazy with very similar circumstances (indexed columns in 
rows missing in a WHERE).

Another cause could be a mismatch between the datatype you 
are passing and the datatype of the column FldListID--and 
that FldListID is an index.

Many databases mis-behave on selects if there isn't an exact 
data match between the type of the index and the type of the 
parameter...for example, a double float (?F) instead of 
integer, or even perhaps its defined as a character field.

I've heard bad things about SP5; that SP6A was better, but 
that's a shot in the dark.

Can you try an ODBC trace--I suspect you will see the value 
"10" being properly passed to SQLServer...next step is a 
SQLServer trace.

Thanks for the help.  Using ?F fixed the problem.  However, 
it doesn't explain why it stopped working in the first 
place - as I am pretty sure no upgrades were done.

Oh well, aren't computers fantastic *grin*.

Reagrds,
Mark.