GATHER MEMVAR, Part 2

GATHER MEMVAR, Part 2

Post by Angel » Sat, 02 May 1998 04:00:00



The reason I used SCATTER/GATHER is this:

I've noticed that a field with a rule, like field>0, will default to 0 when
the table is buffered and APPEND BLANK is used.  My form needs a "Reset"
capability, where in a new record scenario, the user can set the fields back
to 0.  If you do this with REPLACE field WITH 0, the rule fails and no
REPLACE is made.  If you SCATTER MEMVAR, which saves the values you DON'T
want to reset, TABLEREVERT() to get rid of the APPENDed BLANK record, Buffer
(5), append a new record, and GATHER MEMVAR, the hope was that the fields
that need to be 0 would be, while the old field values would be preserved.

GATHER MEMVAR does allow the fields that need to be 0 to be 0, (with
m.FieldToBeZero=0 after the SCATTER MEMVAR), but does not preserve the
non-zero values.

Turns out that in the command window, this process works, but in the form,
it does not.

 
 
 

GATHER MEMVAR, Part 2

Post by Mike Welbor » Sat, 02 May 1998 04:00:00


Hopefully I won't be crucified for posting here, but may I suggest

1) setting your field rule to field>=0.
2) add a record validation rule that requires the fields to be > 0. This way
the record can not be committed until you have valid data and your replace
statement will work at the field level.


>The reason I used SCATTER/GATHER is this:

>I've noticed that a field with a rule, like field>0, will default to 0 when
>the table is buffered and APPEND BLANK is used.  My form needs a "Reset"
>capability, where in a new record scenario, the user can set the fields
back
>to 0.  If you do this with REPLACE field WITH 0, the rule fails and no
>REPLACE is made.  If you SCATTER MEMVAR, which saves the values you DON'T
>want to reset, TABLEREVERT() to get rid of the APPENDed BLANK record,
Buffer
>(5), append a new record, and GATHER MEMVAR, the hope was that the fields
>that need to be 0 would be, while the old field values would be preserved.

>GATHER MEMVAR does allow the fields that need to be 0 to be 0, (with
>m.FieldToBeZero=0 after the SCATTER MEMVAR), but does not preserve the
>non-zero values.

>Turns out that in the command window, this process works, but in the form,
>it does not.


 
 
 

GATHER MEMVAR, Part 2

Post by John Hofstede » Sun, 03 May 1998 04:00:00


This is a clever and elegant solution, but my error handler won't like it
too well.  Regardless, I really appreciate the tip.

Any ideas on why the GATHER isn't restoring the SCATTERed non-zero field
values?

Quote:> Hopefully I won't be crucified for posting here, but may I suggest

> 1) setting your field rule to field>=0.
> 2) add a record validation rule that requires the fields to be > 0. This
way
> the record can not be committed until you have valid data and your
replace
> statement will work at the field level.

 
 
 

GATHER MEMVAR, Part 2

Post by Mike Welbor » Mon, 04 May 1998 04:00:00


Quote:>Any ideas on why the GATHER isn't restoring the SCATTERed non-zero field
>values?

Not really, I don't deal with scatter/gather anymore.

I created a new database and table.
The table had 1 field (field1, N2.0).
I set the field validation rule to field1>0.
I added 1 record with a value of 1

I was unable to replace field1 with 0 - field validation failed as it
should.

I went to the command window, USEd the table, SCATTERed the data, changed
m.field1 to 0, then GATHERed the data. Again the field validation rule
failed(as it should have).

Bottom line, I wasn't able to duplicate your senario. So I must have missed
something.

Mike

 
 
 

GATHER MEMVAR, Part 2

Post by Mike Welbor » Mon, 04 May 1998 04:00:00


OOpps, I just reread the question and realized I focused on the wrong point.

Quote:>Any ideas on why the GATHER isn't restoring the SCATTERed non-zero field
>values?

Gather functions like REPLACE field1 with m.field1, field2 with m.field2,
...

 Which is different from
    replace field1 with m.field1
    replace field2 with m.field2
    .
    .
    .

In the first case, only one replace statement is occurring. So if a field
rule rejects the replace of a particular field,  then the REPLACE statement
fails and nothing is replaced(regardless of wether or not other fields pass
the field validation rule)

Mike

 
 
 

1. Insert Into vs Append Blank/Gather MemVar

Situation:
1)  My target file (jheader.dbf) has a numeric (len=3) field called
division.

2)  My source file (arsystem.dbf) has a character (len=3) field called
division.

3)  I store arsystem.division to m.division. (example: m.division =
"001")

4)  If I select jheader.dbf and insert from memvar, I receive "data
type mismatch".  I feel this is logical - can't put a character value
into a numeric field without using VAL().

5)  If I select jheader.dbf, append blank and gather memvar, I receive
no error and when I browse division = 1.  It (m.division) converted to
numeric. This is what I do not understand.

Why does Gather MemVar work, but Insert from MemVar does not?

Any insight would be appreciated.
Rhonda Tipton.

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

2. Deny access to 'sa' user

3. GATHER MEMVAR glitch

4. Returning Cursor from Stored Procedure

5. Profile of of a DBA - part System Admn / Part Network Admin / Part Web Admin

6. ODBC Administrator

7. Master Parts/Sub Parts/Sub-Sub Parts

8. convert access97 to vb5/sql server?

9. precision parts, bicycle parts, optical parts, electronic components

10. dbase4 MemVar's in reports

11. Clearing from Memvar

12. Quicksilver memvar files

13. Problems with SCATTER MEMVAR