I just spent a couple of hours pounding my head on something and have
discovered an interesting difference in behavior between using a local view and
a remote view. I'm still poking at this a bit but thought I'd toss it out there
to the list to see if others have had similar experiences or otherwise find
this useful. Here's some background:
My main application runs with either a VFP back end or a MSSQL back end
(although there are always DBFs in the mix). There's a main application DBC
that contains the standard tables and views used; local views for VFP systems
and remote views for MSSQL systems. Pretty straightforward stuff from that POV.
I wrote a little single function program a while back that accepts a single
parameter and passes it to one of the standard views in the application DBC.
This function returns a string to me based on the record returned by the view.
The idea is to be able to get this string by calling the function from a report
or anywhere else it might be handy. Here's a mildly sanitized version
(apologies in advance for stupid Outlook wrapping):
LPARAMETERS m.tcReceipt
LOCAL m.lcRetval AS Character, m.receipt AS Character
m.lcRetval=[]
IF NOT EMPTY(m.tcReceipt)
m.receipt=m.tcReceipt
IF NOT USED([mysimpleview])
SET DATABASE TO mymaindb
USE mysimpleview IN 0
ENDIF
REQUERY([mysimpleview])
IF NOT EOF([mysimpleview])
m.lcRetval=IIF(EMPTY(mysimpleview.company),'',;
ALLTRIM(mysimpleview.company)+' (')+ALLTRIM(mysimpleview.lastname)+;
IIF(EMPTY(mysimpleview.firstname),' ',', ')
+ALLTRIM(mysimpleview.firstname)+;
IIF(EMPTY(mysimpleview.company),'',')')
ENDIF
ENDIF
RETURN m.lcRetval
Now comes the odd part. Another developer I work with was looking for something
that returns this particular bit of info and asked if I had done something like
this. He needed to print this information in the group header of a report. Of
course, I say, and pointed him at this prg, told him to drop an object on the
report calling it with the appropriate param value and figured I was done. But
he reported back to me that instead of giving him the correct information, it
was repeating the same result for every report group. The report environment is
pretty simple. There are 2 tables/cursors involved with in a basic parent-child
relationship.
So I test it on my system and it works fine. I watch him test on his and it
doesn't work. Not only does it return the same info from the function call,
it's also repeating other data in the detail band. We log on onto several
different clients and it works as expected. He starts considering Freemanizing
his dev box. Then we try one more client site and the light goes off. The
places where it works (and what I was testing with on my dev system) are using
remote views. What appears to be happening when the report runs on the local
view systems is the record pointer never moves in the child table, and the
value passed to the function comes from the child table. Hence the repeating
values in the report.
The solution at the moment is to simply open the view in the same workarea
every time instead of checking for USED() and REQUERY(). But it took a while to
get there... And I'm still trying to figure out how this interferes with the
normal record movement in a completely different child table but only when
using local views.
--
rk
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/DF1EEF11E586A64FB54A97F22A8BD04419241520F4@ACKBWDDQH1.artfact.local
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
