I see your point about the consistency. One of the areas I have been paying a lot of attention to lately is refactoring, and focusing on code clarity and self documenation. From that point of view, I think that

DTOS()

is easier to read than

DTOC(,1)

To Preserve consistency, what I would do is create the following function

Function TTOS(tdDate)
Return TTOC(tcDate,1)

This way, there would be a matching TTOS and DTOS function, with both being easy to read, and not requiring the ,1 parameter, which is in no way self documenting.

Both structures would certainly work, but given a choice, I would choose the self documenting form over a parameter that I would have to look up when I see it. You may be able to remember all of these parameters offhand, but I, unfortunately, cannot.

>I'm well aware about DTOS() function but DTOC(,1) is consistent with TTOC(,1) which doesn't have TTOS() counterpart.
>
>>You could also use the DTOS() function, which does the same thing as DTOC(,1), but is more readable. This will make your program logic easier to follow in the future.
>>
>>DTOC stands for Date TO Character
>>DTOS stands for Date TO String.
>>
>>DTOC(,1) gives the same functionality as DTOC(,1), but you need to remember what the ',1' parameter does for you.
>>
>>Thus the result I would recommend would be

ssnumber + DTOS(orderdate)

>>
>>>To create a compound index key, you've to convert all fields to the character type.

ssnumber + DTOC(orderdate,1)

Notice the second parameter used in DTOC(,1) function. It converts a date to the text format suitable for an index key.