copy to array fills it with .f.s if qualified 1

[arielap]

This is part of a security maintenance function which works by restoring a list of people from a MEM file into a cursor which the section head can edit.
Clicking 'Save & Exit' from the form with the editable cursor (in a grid) copies the cursor data to an array, which is then saved to the original .MEM

Problem -: simply issuing a 'copy to array pws' is OK but
'copy to array pws for <anything>' results in an array with the correct structure but all fields '.F.'

The same happens if a record in the cursor is deleted and I try 'copy ... for deleted(), or copy with deleted ON.

 

[white605]

What version of fox are you using?
What verson was the original program written in?
Have you tried set compatiable foxplus
Just a guess

wjwjr

This old world keeps spinning round - It's a wonder tall trees ain't layin' down

 

[arielap]

>>What version of fox are you using?
7.0

>>What verson was the original program written in?
Fox DOS 2.6

>>Have you tried set compatiable foxplus
yes

 

[Mike Lewis]

Arielap,

I think the behaviour depends on whether the array exists before you do the COPY. If it does, and if there are no records that meet the FOR condition, the array will retain whatever values it had before.

If it didn't exist before, and if no records meet the condition, the array will be empty.

So, if you have declared or dimensioned the array and then did the COPY, you would get the behaviour you are seeing.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[arielap]

Don't think that's the explanation here.
Experimenting a bit further, independent of the bit of app concerned -:

Using test data files, 10 records x 3 fields, either cursor or permanent DBF-:

'Copy to array <aname>'
copies the data to <aname>, - (as 10,3) as expected
but
'Copy to array <aname> for surname="B"' && 5 names
duly generates an array of 10 rows X 3 columns, but all containing .F.
and the same happens with any FOR clause although
'set filter to surname="B"' before the copy works as it should.

(Even though Copy to array doesn't need explicit dimensioning I did try that too)

Fwiw I'm using VFox 7

 

[Mike Lewis]

'Copy to array <aname>'
copies the data to <aname>, - (as 10,3) as expected
but
'Copy to array <aname> for surname="B"' && 5 names

But did you explicitly RELEASE the array between the two COPYs? My point was that, if the array already exists, and if it is larger than the results produced by the COPY, it will retain its previous dimensions. In other words, the COPY can make it larger, but it won't make it smaller.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[TamarGranor]

Even more importantly, if the array exists and is not big enough, it appears that it doesn't get enlarged.

Tamar

 

[arielap]

>> But did you explicitly RELEASE the array between t

no but I did a 'clear all' - & checked that
'DISP MEMO LIKE ?*' showed nothing, before repeating the commands. ie that the array doesn't exist before the copy-to-array command.

A bit more experimenting -:
copy to array <..> for .t. copies as it should (10x3 ok)

as does copy to array <..> for not empty(name)
_if_ there are no empty names.

as does copy to array <..> next 5 (5x3 ok)

but if I empty a name field in the DBF the 'for not empty(name)' clause creates an array of 9x3 .F.s

>>COPY can make it larger, but it won't make it smaller<<.
Yes, but in this case the array doesn't exist at all until created by the copy command.

What happens if you try this in VFP 9 (which I assume you are using)?. I've no access to anything later than v7

 

[TamarGranor]

Ariela -- I just did the following test in VFP 7 SP1.

CREATE CURSOR TestArray (cFld C(5))
INSERT INTO TestArray VALUES ("aaaaa")
INSERT INTO TestArray VALUES ("bbbbb")
INSERT INTO TestArray VALUES ("")
INSERT INTO TestArray VALUES ("ddddd")

COPY TO ARRAY aTest FOR NOT EMPTY(cFld)
DISPLAY MEMORY LIKE aTest

I got an array with 3 elements containing the three non-empty items.

Just in case this was an issue of multiple columns vs. one column, I tried again like this:

CREATE CURSOR TestArray (cFld C(5), nFld N(3))
INSERT INTO TestArray VALUES ("aaaaa", 123)
INSERT INTO TestArray VALUES ("bbbbb", 342)
INSERT INTO TestArray VALUES ("", 777)
INSERT INTO TestArray VALUES ("ddddd", 787)

COPY TO ARRAY aTest FOR NOT EMPTY(cFld)
DISPLAY MEMORY LIKE aTest

Still worked as expected. So there's something else going on here.

Tamar

 

[DSummZZZ]

Ariela,

Just curious if it's the old EOF() 'gotcha'.
Is there a SET SKIP set on somewhere?
Is there a relation somewhere?
Did you use a NOFILTER clause when you made the cursor?



-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[arielap]

>>Is there a SET SKIP set on somewhere?
>>Is there a relation somewhere?
>>Did you use a NOFILTER clause when you made the cursor?

no to all
I just did 'copy to tst next 10 field surnname, forename, hospno' from the nearest DBF to create the test file

 

[arielap]

>> So there's something else going on here.

must be, but what?

My eg couldn't really be simpler than 2 lines of code -
and I've just run your second test (copy & paste)
and my result was
ATEST Priv A dkb800e3
( 1, 1) L .F.
( 1, 2) L .F.
( 2, 1) L .F.
( 2, 2) L .F.
( 3, 1) L .F.
( 3, 2) L .F.

I note you were using SP1, while I'm running the original v7
Could that be the answer?
(it used to work as expected in FPDos 2.6)

 

[DSummZZZ]

I tried Tamar's example using VFP 7 SP1 as well as VFP 9 SP1 and in both cases, it behaved like you expect.

It sounds like there very could be an anomaly with VFP 7. It wouldn't hurt to install the service pack and see if it makes a difference.

But as a workaround, you could always populate the array 'manually':

STORE FCOUNT() TO nFields
COUNT FOR somecondition TO nHowMany

DIMENSION aArray[nHowMany, nFields]

STORE 0 TO nCounter
SCAN FOR somecondition
   nCounter = nCounter + 1
   FOR zzz = 1 TO nFields
      aArray[nCounter, zzz] = EVALUATE(FIELD(zzz))
   NEXT 
ENDSCAN

-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[TamarGranor]

Figured it out. You must have SET COMPATIBLE ON (or DB4). That is an evil, evil setting that you should never use. SET COMPATIBLE OFF and this will work as expected.

Tamar

 

[arielap]

Thanks
>>It sounds like there very could be an anomaly with VFP 7

Tamar had the answer

 

[arielap]

>>You must have SET COMPATIBLE ON <<

Very many thanks - that was it!

COMPATIBLE was set ON because the original Fox2.6 DOS app is still in occasional use and so the data files need to be kept compatible. I only turned it off for the re-indexing module -else 'dele tag all' didn't work.

(just looked at Help for SET COMPATIBLE - and it seems that it should be _OFF_ for compatibility. A bit unexpected)

 

[Mike Lewis]

Arielap,

COMPATIBLE was set ON because the original Fox2.6 DOS app is still in occasional use and so the data files need to be kept compatible.

SET COMPATIBLE does not affect Fox 2.x data file compatibility. It is intended to provide compatibilty with dBASE III Plus and dBASE IV.

In general, Visual FoxPro can read and write data files that were created in Fox 2.x. No special setting is needed for this. However, Fox 2.x can't read data files created in VFP, or which were amended in VFP in certain ways (such as adding to a DBC, adding NULL support, or adding VFP-specific field types). SET COMPATIBLE does not change that behaviour.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[arielap]

>>Fox 2.x can't read data files created in VFP,<<
So we discovered, early on in the conversion process.

The labs do not have VFP installed and their VFP apps are all stand-alone EXEs, but they often need to use the data (copies of) for statistics etc and can do so using DOS Fox. So all VFP copying is TYPE FOX2X and the app includes a 'convert back to DOS' form.

Incidentally, the Help for SET COMPATIBLE is not only confusing for the non-professional, but also says default is OFF, whereas my VFP starts with it ON.
I've checked the CONFIG.FPW and turned DBASE compat off in Options - so where is it being set ON?

 

[TamarGranor]

The default is definitely OFF. You need to turn it off in Options and click Set as Default to save that, since apparently, you saved it as ON at some point.

Tamar

 

[Mike Lewis]

Arielap,

The labs do not have VFP installed and their VFP apps are all stand-alone EXEs, but they often need to use the data (copies of) for statistics etc and can do so using DOS Fox. So all VFP copying is TYPE FOX2X and the app includes a 'convert back to DOS' form.

Yes, that sounds like the right approach. But my point was that this has got nothing to do with SET COMPATIBLE.

default is OFF, whereas my VFP starts with it ON.

You (or someone) probably went to Tools / Options / General and ticked the "dBASE Compatibility" checkbox, then clicked Set As Default. That would change the default for future sessions. You can just change it back if you wish.

By the way, that particular setting is stored in the registry, not in Config.FPW.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk