I use tabout to produce output tables in Stata 14. I want to drop the last two columns of my table. The handbook states that this can be done using the dropc() option.
This is my code:
tabout var_one var_two if year==2014 using table1.xlsx, ///
cells(freq col) format(0 2p) clab(N %) dropc(5 6) ptotal(none) replace
When I run this I get the following error message:
option dropc() not allowed
The code works fine if I remove the dropc() option. There isn't anything in the handbook that suggests why this is happening and a google search has turned up nothing.
You are using version 2 of the community-contributed command tabout, which is available on SSC.
The aforementioned error arises because option dropc() only works in version 3 beta.
You need to manually install this newer version by downloading the following file from the author's website into your adopath (click here for more information):
http://tabout.net.au/downloads/main_version/tabout.txt
You should also rename the extension to tabout.ado. Note that this is the file for Stata 14 and later.
Once installed, the dropc() option will work:
sysuse auto, clear
tabout mpg price if foreign == 1 using table1.txt, ///
cells(freq col) format(0 2p) dropc(5 6) clab(N %) ptotal(none) replace
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?
I keep receiving an error message that my IF statement has too many arguments. I have used this formula in other excel workbooks and it has worked. Can anyone see what the problem is? Thank you for your help!
=IF(OR(AD2="22",AD2="23",AD2="39",AD2="540",AD2="541",AD2="836"),"1",IF(OR(AD2="335",AD2="312",AD2="364",AD2="367",AD2="311",AD2="336",AD2="365",AD2="319",AD2="368",AD2="488",AD2="498",AD2="461",AD2="501",AD2="505",AD2="531",AD2="462",AD2="489",AD2="491",AD2="491",AD2="493",AD2="507",AD2="457",AD2="460",AD2="499",AD2="503",AD2="509",AD2="513",AD2="539",AD2="612",AD2="613",AD2="568",AD2="821",AD2="827",AD2="829",AD2="835",AD2="845",AD2="846",AD2="615",AD2="620",AD2="614",AD2="691",AD2="719",AD2="873",AD2="877",AD2="32",AD2="427",AD2="373",AD2="465",AD2="502",AD2="511",AD2="466",AD2="475",AD2="481",AD2="500",AD2="504",AD2="462",AD2="489",AD2="491",AD2="493",AD2="507",AD2="503",AD2="513",AD2="539",AD2="607",AD2="610",AD2="608",AD2="609",AD2="611",AD2="579",AD2="769",AD2="795",AD2="827",AD2="831",AD2="834",AD2="837",AD2="838",AD2="839",AD2="840",AD2="841",AD2="842",AD2="843",AD2="851",AD2="852",AD2="853",AD2="854",AD2="856",AD2="857",AD2="860",AD2="861",AD2="868",AD2="869",AD2="870",AD2="871"),"2",IF(OR(AD2="521",AD2="524",AD2="535",AD2="536",AD2="557",AD2="558",AD2="805"),"3","4")))
It seems that the error probably has to do with the limits of version you are using.
Since the formula contains fixed equivalences, I suggest to create a Define Name range then Vlookup cell AD2 to the table in order to obtain the related value:
=IFERROR(VLOOKUP(AD2,_Table,2,0),"4")
This formula should work fine in Excel 2007 and later (I just tested it in 2010 with no issues). The maximum number of arguments allowed in a function in these versions is 255. For earlier versions of Excel though, the max is 30. Since you did not specify which version of Excel you are using, I cannot be 100% sure if this is the problem though but I suspect this is what is going on. I recommend you upgrade to a more current version of the software, but if that's not an option you could always break out the function among multiple cells (In particular, it's the 2nd nested if statement, with ~90 parameters that is causing this...).
I have been using the estout commands for quite some time now, but am now working on a couple of computers that are not connected to the internet. I have been getting the following error from the esttab command:
current estimation results do not have e(b) and e(V)
To test this with a simpler example, I tried to replicate the example here: http://repec.org/bocode/e/estout/estpost.html#estpost101
I created a sample dataset as below:
price mpg rep78 foreign
1 3 1 1
2 3 1 1
3 3 1 2
4 3 2 3
5 3 2 5
6 3 2 8
7 3 3 13
8 3 3 21
9 3 3 34
And then ran the following commands as per the example:
estpost summarize price mpg rep78 foreign, listwise
esttab, cells("mean sd min max") nomtitle nonumber
I got the expected output with the estpost command, but got the aforementioned error when running esttab. I have uninstalled and reinstalled this package several times, using both a version downloaded onto another computer using ssc install and a version downloaded from http://repec.org/bocode/e/estout/installation.html. I feel that I must be missing something obvious...any help would be appreciated.
EDIT: I just checked with a colleague of mine, and it seems they have been inexplicably getting the same error recently.
This works for me. I suspect faulty installation. Despite your best efforts, you may have previously installed versions of some or all of the programs in estout on your system.
In Stata, you need to check what Stata is seeing by typing commands such as
. which esttab, all
in every directory in which you work. If necessary, repeat for all the other command files in the package as named by ssc desc estout. You should be seeing one (and only one) version of each command, dates mostly in 2009 (eststo in 2008).
A wilder hypothesis is that estout has been broken by recent changes in Stata. This seems unlikely to me, but check the above first.
(UPDATE) OP reply reveals a nightmare scenario: old versions have been found that are difficult to remove. What to do?
Look at the adopath command. In the first instance, just type adopath. Stata wants to install estout stuff in an e off whatever it labels PLUS. (If you are in the US, you probably want to say "off of".)
One possibility is that you use adopath to reset PLUS to somewhere you have write access, preferably somewhere dedicated to programs alone. That's got implications for programs already in PLUS, which are now longer visible, so you need to add whatever is now PLUS as an extra place to look. The help for adopath explains how to do this.
Another possibility is that Stata always looks in the current directory or folder for a user-written program before it looks in PLUS (unless you mess with that order, which I advise against). So, so long as programs you want are in the current directory, that should work. However, this would usually be considered poor style. Worse, as you change the working directory, you need to copy programs to that directory.
You may need to approach the administrators to delete the old stuff. It is hard to work with user-written programs for Stata if you don't have the right privileges.
Does anyone know how to use the "execute selection" function in the do-file editor of Stata for code that spans multiple lines?
Currently I can't find a way to do this without using the #delimit ; system which requires repeating "delimit ;" at the beginning of every block I want to run.
Any suggestions appreciated!
I believe that you might be understanding the #delimit ; command wrongly: this is useful when you are coding a do-file to execute it in its entirety afterwards. I also assume that you are using Stata 11, since previous versions behave differently (if I recall well, Stata 10 SE for Mac does not support // comments and delimiting, for example).
If you are executing only a fraction of the code, use /// at the end of a line to continue its command on the next one.
Basic example (that will clear any open data, so beware):
sysuse lifeexp, clear
sc lexp safewater, ///
mlab(country);
This should run flawlessly even if you execute the sysuse command and the sc (scatter) commands separately. The sc command has the mlab option (to add labels to the data points) on a different line, but both lines will be interpreted as only one command due to the /// indication.
Hope this helps!