I see. I wasn't thinking about a table join where a string variable
wouldn't be affected. (Are we 100% certain that the string variable
wouldn't ever be affected? I don't commonly use table joins...)
I think it would be helpful for the programmers to have some short
syntax examples that illustrat
On 26/03/2015 13:00, Alan Mead wrote:
By "I don't think the widest variable should be saved" what exactly do
you mean? If I have email A32 in one file and email A31 in a second
file, if the final merged file has email A31 then one or more email will
be truncated by one character, which means dat
By "I don't think the widest variable should be saved" what exactly do
you mean? If I have email A32 in one file and email A31 in a second
file, if the final merged file has email A31 then one or more email will
be truncated by one character, which means data will be lost. For some
people and some
I don't think the widest variable should be saved - the same old rules
should be followed (eg. in MATCH, if the var is already present leave it
alone). Point is, in 99% of cases the incompatible-width vars are
completely irrelevant for the MATCH at hand, which will fail only
because a feeding f
On 3/26/2015 3:59 AM, ftr wrote:
> So this means that the programs that produce the CSV files produce
> output with different string variable width ?
> This is due to the programs or to the people that use the progs ?
>
> In general, when you import text files you fix the variable width in
> the DA
On 25/03/2015 17:25, Alan Mead wrote:
On 3/25/2015 10:00 AM, ftr wrote:
Frans,
I don't understand why you don't change the variable width for your
string variables. This seems the most easiest way for everyone.
Cheers,
ftr
If you have dozens of variables in dozens of files, it's not "easy
