We found a solution. The developer substituted a truncated date column for the timestamp and it appears to make FileMaker happy. Strange; it was never a problem before. But at least it works.
That does not look like an ESS query. Normally when you do a find on an ESS table, FileMaker will request a list of primary key values with a WHERE clause that matches your find criteria. Something like this:
SELECT id FROM contacts WHERE first_name LIKE '%greg%'
Then FileMaker will do a second query to get up to 25 records at a time with the values for the fields used on the current layout. Something like this:
SELECT id,first_name,last_name,company,address,city,state,zip FROM contacts WHERE id IN (822,848,1560,2108,2885,3861,4591)
Finding the right query from the log should help you figure out what is going on.
Filemaker does not like the date/time fields from Oracle. The other thing to be careful of when using views is that you don't end up with duplicate records, that will really throw FM for a loop.
Thanks, Greg. I didn't think that looked right. She said that was the only query that appeared from the account in question. (We use non-person accounts tied to the application, rather than individuals.) Previously, when working with other DBAs, they've mentioned something called the "SGA" log that apparently had the queries in it. Maybe this DBA's just not looking in the right place?
Thanks, Lee. It's strange; the field type in the shadow table shows up as "Date" whether the developer truncates the field or not. I was told by the users that this search worked before the upgrade, but that might be a red herring.
I'll put it in my "things to remember" list and just have the developers always truncate the timestamp fields from now on.