Hi there, First time poster - I always find results from this forum useful when troubleshooting SAS issues, so though it was worth recording this issue that I encountered. I'm using SAS 9.4. Most of the time, when declaring an array in a DATA step with named variables, I'll use the asterisk, to tell SAS to work out how long to make the array, e.g.: ARRAY parsed_vars(*) arr_var1-arr_var10 _character_; However, sometimes you want to have named variables, and also an explicit range: this is particularly useful when you want your array indices to start at an unusual place, because it's easier to understand. So I tried: ARRAY parsed_vars(0:10) arr_var0-arr_var10 _character_; but it wouldn't work, with an unusual error: ERROR: Too many variables defined for the dimension(s) specified for the array parsed_vars. If I tried e.g. changing the upper-bound 10 to a higher number, (0:20) say, I might get: ERROR: Too few variables defined for the dimension(s) specified for the array parsed_vars. But it wouldn't accept any specific range: even a conventional arr(1:10) var1-var10 would yield a variation on the same error, 'too many' or 'too few', for any upper and lower index I chose. What was the trick? Declare it slightly differently: ARRAY parsed_vars(0:10) $50 arr_var0-arr_var10; The _character_ suffix normally looks for existing variables to use as part of your array, but when the range is unspecified like (*), it doesn't complain: for me it automatically allocated 900-wide character variables, i.e. it interpreted it as an implicit declaration of new variables. For whatever reason, once I introduce an explicit range, it stops using this implicit declaration behaviour: I have to specify my field width for it to work (in this case, $50 for a 50-wide character, for example). It's worth mentioning - the explicit range can be really useful for code readability: in my case, the data it's holding corresponds with field N of some standard, and so it's useful for the var name and array index to use the same N as the corresponding documentation. So parsed_vars(0) = arr_var0, and the contents of arr_var0 corresponds with the 0th field in the spec, etc. There were some other lessons learned - when I tried to make a 'minimal reproducible example' for myself by making a small DATA step without any other complications, omitting an e.g. SET WORK.dataset1; statement made things "look OK" - SAS didn't have to try to instantiate the array when there were no rows of data and so didn't encounter the problem, i.e. it doesn't "statically check" this declaration (unlike other kinds of syntax errors), it only sees it's a problem when it tries to run it.
... View more