>>>I agree that certrain rules should be folowed by all means, but we all know
>>>that there are exceptions to meny rules. I was just trying find out if this is one of those situations, or it is really something serious enough to bear in mind next time I am about to create memory cursor.
>>>Only thing I would consider serious here if index file gets corrupted
>>>otherwise I can't see much harm in it, beside violating rule established
>>>to prevent some other harm.
>>>
>>>If harm does not happen, does rule still apply ?
>>
>>Absolutely. Why use a risky technique? You might trip over it later. Then you'll have to spend time trying to understand what went wrong. They you'll have to spend time to fix it by doing what should have been done in the first place? Furthermore, how much changing will it require to remove every place you've done this "trick"?
>>
>>I love to show clients discussions like this.
>
>Ok using risky technique is bad, but can we also analyse nature of
>damage and consequently level of the risk ?
>Is there really any risk/damage when applied on memory cursor ?
>From your and Hector's examples I wld say that this rule is more
>oriented/applicable to creating (free) tables on hard disk for further
>use. If cursor is to be created and consumed right there & then what
>are possible consequences ?
>
>In my case (most of the source kept in prg) it would take me
>aprox 10 minutes to hunt down all create cursor statements used
>and 'rectify'; but I wld like to hear/understand first what can possibly go
>wrong if this 'mistake' is done on create cursor command that short lives
>in memory within (data)session object.
>I don't use free tables not so ever, nor do I create databases/tables
>in code. We are talking about few situations with composite indexes and always on tmp memory cursor.
>
>So what is my risk ?
>Except violating coding rule and then getting 'shouted at' by seniors :)

You are a software designer / engineer. The risk in using a risky technique will fall on your customers/users. You do not take a risk just for yourself.

Further you increase the likelihood that you will add the alias to a place where it should not be used - because of habit or imperfect human memory. Will you hunt down this discussion each time? ;)

It's difficult to prove this is something bad. If you jaywalk, does someone have to hit you with a car before you'll stop? ;)

A "temporary cursor" may not be as "temporary" as you think. Suppose you extract a set of records from a backend to a cursor for a combobox. Later you or someone else on your team adds some code. This new code is "smart". It uses the cursor again with a different alias. Why go to the back-end again when the cursor is already downloaded? Everything seems fine, but try a BROWSE after running the following:

create CURSOR c_test (cvalue c(10))
for i=1 to 100
	insert into c_test (cvalue) values (Sys(2015))
next i
index on c_test.cvalue tag ixvalue

SELECT 0
USE DBF("c_test") AGAIN ALIAS otheralias

USE IN c_test

SELECT otheralias
SET ORDER TO IXVALUE descending

How much effort should be expended trying to prove there is nothing good in this technique - no matter where it is used? There's more than enough to remember just trying to keep track of the good techniques.