I'm a newcomer to Stata after using R for a long time.
I'm trying to perform any action which involves a macro, such as a loop and it is constantly giving me an invalid name r(198) error.
For example, when I first start up Stata, I enter the following code into the command prompt:
local hello 123
di 'hello'
This results in:
'hello' invalid name
r(198);
Similarly, I try:
forvalues i=1/5 {
display 'i'
}
Which results in the same invalid name error.
I'm obviously doing something fundamentally wrong. I have tried putting the same commands into a do file and running them, but the same thing occurred.
I was wondering if it's something to do with how I'm running the code as this link alludes to, but nothing suggested there worked for me.
I'm running Stata remotely from a server, if that could affect anything.
Related
the code was ok, but in the second time is not working even though the variable is named differently[][Here is a picture of the error that I'm receiving]I'm working on bankscope database and there are some duplicates. Hence, I'm trying to overcome the duplication. I have tried this following code
foreach var of varlist address website phone fax {
qui duplicates tag `var' year cntrycde ///
if `var'~="", gen(dup_entry)
}
However, I kept receiving an error message which says
(invalid name)
r(198)
Can you help to overcome this issue?
I am using feedparser to parse RSS feed from spotcrime
However, I am getting "no attribute" error whenever I'm trying to loop through the entries to get the 'geo_long' and 'geo_lat' attribute.
If I don't loop than it works fine:
f = feedparser.parse(link)
entries = f.entries
print entries[0].geo_long
But when I do it in a loop like this, it starts giving me error
for e in entries:
print e.geo_long
And this error is only for geo_long/geo_lat/where attribute on my feed. Other attributes work just fine when accessed in a loop. Can someone please let me know the problem? Thanks
I found a way to go around this by using e.get('geo_long') instead and it worked. Still don't know why the other way does not work though
I have a scenario where in need to compare the amount and if they don't match ABORT the session.
I have done the below logic, but some how the ABORT function is not working.(Error says has an error evaluating variable column)
this is what i did:
i have 3 source columns DLY_NET_AMT_DUE, WKLY_INVCD_AMT, INV_CHARGE_AMOUNT. All are inputs. I used a variable port and said
v_INV_CHARGE_AMOUNT=iif((DLY_NET_AMT_DUE=WKLY_INVCD_AMT) and
(WKLY_INVCD_AMT=INV_CHARGE_AMOUNT),'Amount Balanced',ABORT('Amount Not Balanced'))
o_INV_CHARGE_AMOUNT=v_INV_CHARGE_AMOUNT
Could you guys please help me where am i going wrong.
Please paste the exact error message.
If possible, share the transformation screenshot
What is the datatype of v_INV_CHARGE_AMOUNT port? Is it possible that it's decimal and the error is caused by trying to put Amount Balanced as value?
Did you try to run debugger and do the Evaluate expression?
I have the following code that is running inside a macro. When it is run in interactive mode, it runs absolutely fine, no errors or warning. That was the case for last two year.
The same code has now been deployed in batch mode and it generates a warning WARNING: Apparent symbolic reference FIRSTRECCOUNT not resolved. and no value assigned to macro variable.
My question is, does anyone have any ideas why batch mode and interactive mode would behave differently?
Here some more information:
The dataset is being created and it is in work library.
The dataset does get opened by data step.
`firstreccount' doesn't get initialiased anywhere else in the program
I have search sas community. There is a topic here, but I don't have the same errors in batch initilisation as described in the answer.
Detailed information on the warning but it doesn't explain by it would work in interactive mode, but not in batch mode.
.
1735 %LET FIRSTSET = work.dataset1;
1744 DATA _NULL_;
1745 IF 0 THEN
1746 SET &FIRSTSET NOBS=X;
1747 CALL SYMPUT('FIRSTRECCOUNT' ,X);
1748 STOP;
1749 RUN;
1755 DATA _NULL_;
1756 IF 0 THEN
1757 SET &SECONDSET NOBS=X;
1758 CALL SYMPUT('SECONDRECOUNT' ,X);
1759 STOP;
1760 RUN;
WARNING: Apparent symbolic reference FIRSTRECCOUNT not resolved.
Update:
So I have attempted to replicate the error by copying the code with warning into a separate scheduled flow, but it didn't cause any errors at all.
By the way, the original job was deployed from SAS DI studio. I have checked all lines in user written code nodes and made sure that the length was within 80 characters as recommended by #RawFocus, #RobertPentridge, but it didn't solve the issue.
As recomended by #data_null_ I have checked VALIDVARNAME and it was different between interactive (value of "any") and batch mode (value of "V7") but changing these hasn't made any difference.
I have rewritted the logic to get the number of observations by calling attr for an open dataset. This eliminated the warning, but program would still fail with warning popping out in different places. It made me think Robert Partridge is correct. At the same time, I got an error that a macro not being resolved. The macro was inserted by DI studio to collect performance MI even that the job wasn't meant to be collecting MI. This made me think that SAS DI studio is not generating code correctly when deploying it, so I manually edited the deployed code to remove offending macro call and I also spotted that there was one line of code with MD5 function that was too long on one line because of a number of parameters being passed to it, so I inserted some white space. And finally the problem was fixed!!
I still need to do something about the job because when it will get redeployed from SAS DI, it will generate the same errors again. I don't have time to look into this further at the moment.
Conclusion: what you write in SAS DI and what gets deployed could be slightly different which could cause syntax parse to throw errors in random places. So I will mark Robert's answer as correct because it got me closer to solving the problem then any other answer.
The problem could be happening above the code snippet you pasted. The parser got into a funk earlier, and ended up issuing warning about code that is perfectly fine.
Check to make sure that no code within a macro is longer that ~160 chars on a single line. I try to keep my code well below that but long lines of code can run fine interactively and fail in batch - particularly when inside of a macro.
I expect your program has some small error above that does not cause SAS to go into syntax check mode when run interactively but does cause SAS to set obs to 0 and enter syntax check mode when run in batch.
One possibility is the limit (in batch mode) of the length of a line in your submitted SAS program:
See: http://support.sas.com/kb/15/883.html
Which version of SAS are you running?
Why does Stata complain with a cryptic error when I use string variables in the table command?
Consider the following toy example:
sysuse auto, clear
decode foreign, g(foreign_str)
table foreign, contents(n foreign_str mean mpg)
This raises an r(111) variable __000002 not found error in Stata 13.1.
Tracing the error tells me that it is trying to run format __000002 %9.0gc and crashing when it does not find the variable. If I switch the order of the variables in the clist, that is i run table foreign, contents(n mpg_rank mean mpg), I get the same error but with __000003 instead of __000002.
So it appears that Stata crashes when it finds the string variable. If I replace the string variable with a numeric variable, the error doesn't occur.
I know it is not meaningful to compute summary statistics on string variables, but counting the number of observations of a string variable (in each group specified by the rowvar) makes perfect sense.
Stata complains because variable __000002 (or __000003 if you change the order) is not created by the collapse command (which is used internally by table) due to the following error:
collapse (count) foreign_str
type mismatch
r(109);
What really happens is not visible to the user because capture is used in combination with collapse and the output from trace confirms that:
- capture collapse `clist' `wgt', by(`varlist' `by') fast `cw'
= capture collapse (count) __000002=foreign_str (mean) __000003=mpg , by(foreign ) fast
There are only provisions for error codes 111 and 135, so the table command continues to run until it hits a wall when it cannot find the aforementioned variables.
Stata 14 and later versions check the variable(s) provided by the user in the contents() option and only accept numeric types, issuing a more informative error message if this is not the case.
It is also worth pointing out that collapse treats strings differently in more recent Stata versions.