Weird report run

GCC Consulting gccconsulting at comcast.net
Wed Sep 13 12:19:56 PDT 2006


 



  _____  

From: filepro-list-bounces+gccconsulting=comcast.net at lists.celestial.com
[mailto:filepro-list-bounces+gccconsulting=comcast.net at lists.celestial.com]
On Behalf Of Boaz Bezborodko
Sent: Wednesday, September 13, 2006 2:38 PM
To: joe at magnatechonline.com
Cc: filepro-list at lists.celestial.com
Subject: Re: Weird report run


In this case the selection set is based on a 1 character wide flag-type
field.  The sort and form-breaks were done on the Vendor name in the sort
table for the form.  So while the selection might have been played with the
sort and printout should still have broken out OK.  Except that that's not
what happened. 

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.

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).  But
to select them erroneously, properly process them, and then put them on the
same form without the form-breaks just seems very strange.

Boaz
 
Have you looked at the selection set since the problem.  Is it as it should
be?
 
Richard Kreiss
 
 
 
Joe Chasan wrote: 

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

  

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.

    



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



  

Joe Chasan wrote:



    

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:

 



      

Through a selection set.  (Looking for a "Y" in a particular field.)



GCC Consulting wrote:



   



        

     



          

-----Original Message-----

From: 

filepro-list-bounces+gccconsulting=comcast.net at lists.celestial

.com 

[mailto:filepro-list-bounces+gccconsulting=comcast.net at lists.c

elestial.com] On Behalf Of Boaz Bezborodko

Sent: Wednesday, September 13, 2006 1:11 PM

To: filepro-list at lists.celestial.com

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

  



       



            

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













     



          

 



      

_______________________________________________

Filepro-list mailing list

Filepro-list at lists.celestial.com

http://mailman.celestial.com/mailman/listinfo/filepro-list

   



        

--- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ---

-Joe Chasan-                      Magnatech Business Systems, Inc.

joe at magnatechonline.com           Hicksville, NY - USA

http://www.MagnatechOnline.com    Tel.(516) 931-4444/Fax.(516) 931-1264



 



      

--- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ---

-Joe Chasan-                      Magnatech Business Systems, Inc.

joe at magnatechonline.com           Hicksville, NY - USA

http://www.MagnatechOnline.com    Tel.(516) 931-4444/Fax.(516) 931-1264



  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.celestial.com/pipermail/filepro-list/attachments/20060913/9201c0c8/attachment-0001.html


More information about the Filepro-list mailing list