I would still check that they all exist, what type they are, and their values. What version of VFP is it? 8 or earlier? Have you tried tweaking with sys(3050)?

It's important to verify the vars exist, are of the right type, and their values since the error occurs on that line. If they are not, then perhaps memory has come into play, but then you can research why they are not and if it has to do with terminal services or not.

Also, I ran into configuration issues with TS2003. Does it work fine with TS2003? You might look at my issues here and see if anything helps:

Terminal Services and config.fpw Thread #1028312 Message #1028312



>Tracy
>
>The line of code is not the problem. It works on every other installation across the state except this one 2008 terminal services installation. The problems are coming up through interaction with the terminal services. I'm looking for information on that interaction and anything that might be creating the performance problem
>
>
>>>Hey All
>>>
>>>We've got an office that is running our application and their MIS Director likes to have the latest and greatest everything.
>>>
>>>This is what I know:
>>>
>>>Depending on what they are doing in our application, they either get to it through Citrix or through 2008 terminal server on VMWare. The reason they moved certain things off Citrix was because of a screen painting problem on one of our modules.
>>>
>>>What they are seeing is a massive performance hit on the 2008 terminal server. To quote our Custormer Service person, "It's DOG slow". If they RDP into the box this perfomance hit goes away. I know this is a REAL general description, so what I'm looking for, first off, is top-level suggestions, along with suggestions of what we SHOULD be asking him.
>>>
>>>The other issue is, when running through the 2008 terminal services, they get the following error
>>>
>>>
>>>"Function argument value, type or count is invalid" on the following line of code
>>>

>>>if lnCount <=ALEN(afl679) and RIGHT(afl679(lnCount), len(tnSearch)) # tnSearch
>>>

>>>The above line of code works everywhere else (10 other sites).
>>>
>>>Obviously, I don't know what information I should be asking for, so anything would be appreciated.
>>
>>Put something in place to store those values to a file on the hard drive so you can capture the status on their system. One option is to load some public values from a table that you can turn off/on to control capturing that information:
>>
>>1) Create a public variable glTrack or something that describes your testing
>>2) Set it to .F. in your main program
>>3) Create a table to read variables from that hold the variable name and value i.e. varname, varvalue (make varvalue char and change it as nec)
>>4) Add a record in the table for that variable and set its value to .T. (".T." in the table)
>>5) Loop through the records in that table in your main program to set those values globally in your app (you can turn it off later by changing the value in the record to .F. if you wish
>>6) Before your code, enclose it in something like:
>>
>>

>>IF glTrack
>>   lcMessage = ""
>>   lcMessage = lcMessage + " lncount type is: "+TYPE('lncount')+CHR(13)
>>   DO CASE
>>      CASE TYPE('lnCount') = "N"
>>            lcMessage = lcMessage + " lncount value is: "+ALLTRIm(STR(lncount))+CHR(13)   
>>      CASE TYPE('lnCount') = "C"
>>            lcMessage = lcMessage + " lncount value is: "+lncount+chr(13)
>>      *etc...for all types
>>   ENDCASE
>>   *etc...add checks for the other variables you are checking: ALEN(afl679), afl679, tnsearch, etc
>>   *use strtofile() to store lcmessage to a file you can check later
>>ELSE
>>   *normal processing
>>ENDIF
>>

>>
>>after you capture the individual var types and values, don't forget to try to capture the values for your functions such as: RIGHT(afl679(lnCount), len(tnSearch))
>>put it inside a TRY...CATCH in case that is the part that is bombing