Compiler doesn't know the actual data types like me:) So it would pass.
I'd put a test before that replace that lists the types of all memvars + fields.
PS: You're saying import. Import (which I almost never use) might be getting with type conversions. Instead you might create a cursor beforehand where all fields are char and append. Any type there would be implicitly convertible to char. Date is supicious that it might be coming in as an integer. I'd write out the intermediate cursor to a text file and append from in new which does the conversions on the fly (I mean no need to replace it seems).
Cetin

>Cetin,
>
>Oooooooooooh yeah! Well spotted. Well I'll be ... it does actually go through without any compiler complaint and run stand-alone in VFP without complaint.
>
>And another one:
>

>  	 Route	 with PADL( ALLTRIM( m.E), 4, "0");
>
>

>
>:-(
>
>I then rebuild the project->exe in FPD, again without complaint (hmmmm. maybe the prog has already "passed muster" in VFP so doesn't get recompiled in FPD?) - I guess anyway that the compiler was a lot slacker back then anyway.
>
>So I've fixed the code and rebuilt but, alas, it still fails on the replace line (works like a dream in VFP), so the original question still stands.
>
>Cheers
>
>Terry
>
>>Terry,
>>Does this really work under VFP? If yes then I think there is a typo when writing here.
>>
>> OStage with PADL( ALLTRIM( m.W), 4, "0");
>> DStage with PADL( ALLTRIM( m.Y), 4, "0");
>>
>>Cetin
>>
>>>Hi Foxperts
>>>
>>>A bit tricky this. My program takes an Excel 3 spreadsheet and converts it to a FPD2.6 table, in FPD.
>>>
>>>First the XLS is IMPORTed to an intermediary table where the data types of the fields can't be determined from the original spreadsheet. I don't understand what mechanism governs this but it doesn't seem to be consistant with the cell formats (besides, there are column header text cells above numeric or char data in the sheet).
>>>
>>>Anyway, in development I ascertained the field types of the inter. table (with fields named after the XLS column letters), so that I could convert them as appropriate into the final table, thus:
>>>

>>>Scan
>>>  Scatter MEMVAR
>>>  Select DestFB1
>>>  Append Blank
>>>
>>>* These are S/S col heads->field names
>>>* ____________________________________
>>>  Replace Operator	 with tnOperator, ;	
>>>          Journey	 with VAL( m.B), ;	
>>>  	 Route	 with PADL( ALLTRIM( m.E), 4, "0");
>>>  	 Date	 with CTOD( m.H), ;
>>>  	 Class	 with PADL( ALLTRIM( STR( m.K, 4)), 4, "0"), ;
>>>  	 TickTime with m.M, ;
>>>  	 Number	 with VAL( m.O), ;
>>>  	 Fare	 with VAL( m.R), ;
>>>  	 Value	 with VAL( m.T) * 100, ;
>>>  	 OStage	 with PADL( ALLTRIM( m.W), 4, "0");
>>>  	 DStage	 with PADL( ALLTRIM( m.Y), 4, "0");
>>>  	 Driver	 with VAL( m.Aa), ;
>>>  	 Bus	 with VAL( m.Ac), ;
>>>  	 Duty	 with VAL( m.Ae)
>>>EndScan
>>>

>>>
>>>Now I use the convenience of VFP and its debugger to test run this and it works fine. Then I rebuild the FPD project and produce a new exe. But when I run the exe I get a data type m/m on the above replace line.
>>>
>>>OK I know I can isolate each field with its own replace, and that will tell me which one if fails on (which I've already done to perfect the code) but that doesn't stop the fact that at least one of the fields seems to give a different data type whether in VFP or FPD.
>>>
>>>I'm using FPD tables that don't get converted to VFP
>>>
>>>Any experience/knowledge/advice etc. on this?
>>>
>>>'ppreciate it
>>>
>>>Terry