<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2963" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff 
size=2></FONT>&nbsp;</DIV><FONT face=Arial color=#0000ff size=2></FONT><BR>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> 
  filepro-list-bounces+gccconsulting=comcast.net@lists.celestial.com 
  [mailto:filepro-list-bounces+gccconsulting=comcast.net@lists.celestial.com] 
  <B>On Behalf Of </B>Boaz Bezborodko<BR><B>Sent:</B> Wednesday, September 13, 
  2006 2:38 PM<BR><B>To:</B> joe@magnatechonline.com<BR><B>Cc:</B> 
  filepro-list@lists.celestial.com<BR><B>Subject:</B> Re: Weird report 
  run<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV>In this case the selection set is based on a 1 character wide flag-type 
  field.&nbsp; The sort and form-breaks were done on the Vendor name in the sort 
  table for the form.&nbsp; So while the selection might have been played with 
  the sort and printout should still have broken out OK.&nbsp; Except that 
  that's not what happened. <BR><BR>The user assures me that they used the 
  system to select only the one invoice, but the system selected a bunch or 
  other, seemingly random, invoices and put them on the same form even as it 
  generated new check records for them.<BR><BR>As I said, generating the checks 
  would not have been strange if it wasn't for the user swearing that they 
  weren't selected (and I believe him).&nbsp; But to select them erroneously, 
  properly process them, and then put them on the same form without the 
  form-breaks just seems very strange.<BR><BR>Boaz<BR><SPAN 
  class=538011919-13092006><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=538011919-13092006><FONT face=Arial color=#0000ff size=2>Have 
  you looked at the selection set since the problem.&nbsp; Is it as it should 
  be?</FONT></SPAN></DIV>
  <DIV><SPAN class=538011919-13092006><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=538011919-13092006><FONT face=Arial color=#0000ff 
  size=2>Richard Kreiss</FONT></SPAN></DIV>
  <DIV><SPAN class=538011919-13092006><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=538011919-13092006><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=538011919-13092006>&nbsp;</SPAN><BR>Joe Chasan wrote: </DIV>
  <BLOCKQUOTE cite=mid20060913140041.A22241@magnatechonline.com type="cite"><PRE wrap="">On Wed, Sep 13, 2006 at 01:49:32PM -0400, Boaz Bezborodko wrote:
  </PRE>
    <BLOCKQUOTE type="cite"><PRE wrap="">Knowing the user I would seriously doubt that either of these were
played with.  In any case it wouldn't explain the other weird behavior
of why the output didn't break into separate forms.
    </PRE></BLOCKQUOTE><PRE wrap=""><!---->
yes, it could.

take the below example.

vendor number field is of length 6.  you sort/subtotal by that field 
number.

report selects data for vendor #100001, 100002, 100003.

if sort is of length 6, these will appear in different subtotal groupings
and/or pages depending on how you have set this up - all well and good.

lets say, however,that the sort length is of a number less than 6 - for
the above 3 data items, a length 0, 1, 2, 3, 4, or 5 will all put these
items in the same grouping as the first X (where X is 0/1/2/3/4/5 per above)
number of characters of those fields are the same.

-joe

  </PRE>
    <BLOCKQUOTE type="cite"><PRE wrap="">Joe Chasan wrote:

    </PRE>
      <BLOCKQUOTE type="cite"><PRE wrap="">if the user has access to modify either the selection set or the sort
criteria, i'd look at those as possible causes.

-joe

On Wed, Sep 13, 2006 at 01:31:13PM -0400, Boaz Bezborodko wrote:
 

      </PRE>
        <BLOCKQUOTE type="cite"><PRE wrap="">Through a selection set.  (Looking for a "Y" in a particular field.)

GCC Consulting wrote:

   

        </PRE>
          <BLOCKQUOTE type="cite"><PRE wrap="">     

          </PRE>
            <BLOCKQUOTE type="cite"><PRE wrap="">-----Original Message-----
From: 
<A class=moz-txt-link-abbreviated href="mailto:filepro-list-bounces+gccconsulting=comcast.net@lists.celestial">filepro-list-bounces+gccconsulting=comcast.net@lists.celestial</A>
.com 
[<A class=moz-txt-link-freetext href="mailto:filepro-list-bounces+gccconsulting=comcast.net@lists.c">mailto:filepro-list-bounces+gccconsulting=comcast.net@lists.c</A>
elestial.com] On Behalf Of Boaz Bezborodko
Sent: Wednesday, September 13, 2006 1:11 PM
To: <A class=moz-txt-link-abbreviated href="mailto:filepro-list@lists.celestial.com">filepro-list@lists.celestial.com</A>
Subject: Weird report run

A user ran a report that had a very weird result and I need 
help trying to figure out why.  This is a report that has 
been running fine for a long time.

The report picks out invoices to pay and then generates 
checks for them.  Each invoice is a line on the report and 
the sort order is by vendor with a new form being generated 
for each new vendor.  When it does so it generates a new 
check number and creates a new record for this check in the 
checks file.

The weird thing on this run was that on this run they were 
only generating one check, but a bunch o invoices that should 
not have been selected, from different vendors, were chosen 
and they were printed all on the first form for the original 
check.  They should not have been selected, but they were.  
They should not have shown up on the first form as part of 
the one check that was supposed to have run, but they did.  
And they should not have generated their own checks, but they 
did.  That last part was the one part that was consistent 
with their being printed even though they shouldn't have 
because they didn't conform to the selection criteria.

I've reviewed the code and can't find any reason why this 
should have happened.  Any suggestions as to why the errant 
selection and sort behavior?

Note:  I'm using FP 4.8 on Windows.

Boaz
  

       

            </PRE></BLOCKQUOTE><PRE wrap="">What is the criteria that you are using to select invoice to pay?

Is this through -v processing or a selection set?

Richard Kreiss
GCC Consulting






     

          </PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=""> 

      </PRE>
        <BLOCKQUOTE type="cite"><PRE wrap="">_______________________________________________
Filepro-list mailing list
<A class=moz-txt-link-abbreviated href="mailto:Filepro-list@lists.celestial.com">Filepro-list@lists.celestial.com</A>
<A class=moz-txt-link-freetext href="http://mailman.celestial.com/mailman/listinfo/filepro-list">http://mailman.celestial.com/mailman/listinfo/filepro-list</A>
   

        </PRE></BLOCKQUOTE><PRE wrap="">--- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ---
-Joe Chasan-                      Magnatech Business Systems, Inc.
<A class=moz-txt-link-abbreviated href="mailto:joe@magnatechonline.com">joe@magnatechonline.com</A>           Hicksville, NY - USA
<A class=moz-txt-link-freetext href="http://www.MagnatechOnline.com">http://www.MagnatechOnline.com</A>    Tel.(516) 931-4444/Fax.(516) 931-1264

 

      </PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=""><!---->--- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ---
-Joe Chasan-                      Magnatech Business Systems, Inc.
<A class=moz-txt-link-abbreviated href="mailto:joe@magnatechonline.com">joe@magnatechonline.com</A>           Hicksville, NY - USA
<A class=moz-txt-link-freetext href="http://www.MagnatechOnline.com">http://www.MagnatechOnline.com</A>    Tel.(516) 931-4444/Fax.(516) 931-1264

  </PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>