I have a do file from which I would like to select a few lines of code and then run them using the Execute (do) button. The problem is that there are a bunch of local macros defined in this do file. I can run them, but then in the Stata command prompt the local macros are not accessible. Thus, I think I should just be using global macros.
I have looked in several places and haven't been able to find out what scope macro variables actually have. I realize that local macros are only defined in the instance (for example, a do file) they are originally created in.
But for global macros, are they stored forever and every time I open up a new instance of Stata I will still have the global macros from previous sessions?
Or do they get deleted each time I exit out of Stata (or something else)?
Global means visible everywhere, but not for all time.
Global macros you create disappear at the end of a session.
When you start a session, or indeed at any time, macro list shows global and also local macros visible within your current locale. Here "locale" is not a word used in Stata documentation, but a nonce coinage to denote the current interactive session, the current program, the current contents of the do-file editor or a selection thereof, namely the code currently running. The difference is that local macros are only visible within the locale in which they are defined; global macros are visible in any locale.
Some global macros appear to be created on the fly; thus if I wish for a display of current date or time I can
di "$S_DATE"
di "$S_TIME"
and Stata will access the operating system for such details.
But the easiest way to answer your question is to experiment. Define some global such as
global whoami "bill999"
di "$whoami"
and then sign off and start a new session and see whether it is saved by Stata. Alternatively, save the current dataset and use the same dataset in a new session and see whether globals survive the journey.
See also help notes.
Related
Currently I am trying to run a SAS program using VBA. Using the SAS Add-In For Microsoft Office, I created a stored process that contains a generic code that creates a dummy table. Inside SAS EG, I am able to run the Stored Process normally, and also inside the Excel environment, using the InsertStoredProcess function of the SASExcelAddIn object. Regardless of the environment used to run my Stored Process, the behavior of the SAS Sessions are the same: one session is created when I start to run and another one is created during the process. However, that is where my problem comes. When the process finishes, I continue with the two sessions as active, and every time I try to run again my Stored Process, one new session is created over the ones that already existed. The sessions close only when I manually disconnect from the SAS Server I'm connected or when I close the Excel. Since my organization allows only three concurrent sessions, this is becoming a big problem for me.
I already tried to use the ABORT macro function inside my code, the rc=stpsrv_session('delete') command and delete the Stored Process from the Excel worksheet, and none of them solved my problem.
Any ideas of what I'm missing here? Is there a way to end the SAS Session after the Stored Process ends?
First of all, you shouldn't use VBA to do any of this. If in Office products, use VSTO and C#. I am in the throes of converting thousands of lines of VBA to C#/VSTO. VBA is very obsolete which is why the code is being converted.
Second, EG is built using C# so it is more natural to use. You can even create custom tasks using C# in EG.
You need to close out your sessions after they are started. See this post at SAS for how to close out your sessions in VBA: https://communities.sas.com/t5/SAS-Enterprise-Guide/Calling-SAS-through-VBA/td-p/79673
Again, you should stop using VBA and switch over. It will be much easier. VSTO is free and is made to interact with Office. Use Visual Studio to create your project. The C# code for working with SAS can be found using any of Chris Hemendinger's post (SAS community manager) or you can refer to links on my github repos here: https://github.com/savian-net
I need to add a bunch of DOCVARIABLES to a word document for my work. The end goal is to use C# to easily ask a user what values need to go into those variables, then automatically generate the word document from the template with empty variables.
Despite having gone through and added all the field codes for the variables, when I save the document it doesn't actually initialize any of the document variables to a state where they exist, and so when I use C#, it can't find any of them. When I check the docx as a zip file, there are no <w:docVars> tags in the settings.xml file. When I add the DOCVARIABLES using the C# instead of directly through word, those tags are added.
All of the solutions I've found so far involve using a VBA Macro to initialize them to something, but that isn't an option here because, for whatever reason, we aren't allowed to use VBA Macros at all because corporate something something. There is some restriction on the computers that corporate requires them to have that entirely prevents me from running those macros, and trying to bypass that is not an option.
How do I get the DOCVARIABLES to initialize to some initial value that will allow the C# to find them?
DocVariables cannot be blank. If you set one to a null value, it is removed.
As a workaround set an initial value to “Empty” and then have your code check for that value and take appropriate action. Otherwise, just simple check if the DocVariable exists and take appropriate action if it does not.
Update:
DocVariables must be created from a macro. The macro can be in the document, a document template, or a global add-in. All require permission to run and if the IT department won’t approve any of those solutions, then DocVariables are not really an automation option.
What are some alternatives to using the clipboard feature in Automation Anywhere? I'm told using the clipboard feature is not ideal for consistency.
You can create a variable instead of using clipboard.
Steps to create variable:
Select the variable manager from the extreme right side of workbench window
click on Add at the bottom of variable manager section
In Add Variable window, provide the details of the variable which needs to be created
You can refer How to create variables in Automation Anywhere Client
That is True. Even if user is not using the system while AA bot is running, some background services might kick in and use clipboard(only id programmer have used it)
Note: Sometimes, depending on situation. Like a secure excel files where if we need to copy data between workbooks/sheets, we are stuck with Ctrl+C and Ctrl+V
Alternatives go as below:
1. For values, use variables instead of clipboard
2. Excel files, use Get Cell and Set Cell also consider connecting to Excel as database
3. File Copy, use the Copy File option
I cannot think of anymore scenarios as of now, but let me know what exactly were you trying to do.
You should use 'Prompt-Assignment' variable for holding temporary values. Use of 'Clipboard' should only be done where a Ctrl+C action needs to be performed however the value should immediately be transferred in 'Prompt-Assignment' or any other variable for holding the values.
You can use other system variables according to the application you are using
For ex:
Excel : Excel Column
CSV/TXT : FileData Column
These system variable will hold the values inside the loop only. you can assign in to some other custom variable and you can use it anywhere.
please bear with me, I use Automator since not long.
I have good experience in PHP (totally different) and some small scripting knowledge (apple script, shell, etc).
I try to replicate this logic workflow with Automator:
Ask User to insert value (set $variable_a)
Ask User to insert one more value (set $variable_b)
Submit
This triggers a script that uses both values submitted above. A dummy example:
echo $variable_a
echo variable_b
Seems simple, and it's amazing how fast you can set up this logic with Automator.
The problem is, at stage 2 above, my $variable_a is suddenly a mixed value of $variable_a and $variable_b.
Why does this happen?
They do not seem to act as I understand the generic usage of "variables" in any language or programming step.
In other systems, usually, variables keep as value what they got defined (unless variable variables or you modify them consciously in the code)
I attached an Automator "WorkFlow" File that replicates exactly the abovementioned WorkFlow Logic.
It's a ZIP file, unzip it and open in Automator for a test.
You will see (in the results section for the last step) how the values become (IMHO) false.
Has someone a hint?
The reason this is happening is because the output of one action in the workflow is being fed as input into the next action of the workflow. As inputs are received by actions, they can also aggregate in some cases, such as when setting and getting variables.
The reason it does this is so that you could sent multiple variables directly into, say, a Run Shell Script action, and references them using $1, $2, etc. If Automator only ever took the most recent input, you'd never be able to feed more than one variable into a shell script without first combining them manually yourself into a list.
The solution is simple. Every action has an Options button that you can press, which in turn reveals a checkbox called Ignore this action's input. This needs to be checked for those actions that you want to operate independently of previous results.
Here's a screenshot of your workflow with the appropriate checkboxes ticked against the actions that require it:
END GAME: A user saved Workbook opens and mirrors code from a target file.
I am trying to create a simple VBA application that has an Excel front-end and an Access back-end. There will be multiple users who would have the option to save the front-end Excel piece anywhere they desire.
I would like to know the most efficient way to be able to update macros in all user instances when I need to push updates.
Essentially, I would like to mirror code from a "global" file on Workbook_open. In the past I did actually set code to open a separate workbook and run code (dim x as workbook, open, app.runmacro and etc.), But I think that is not really the most efficient way to do it.
Four possible solutions pop to mind for this (other than your option of having an intermediary workbook), there are likely others:
Treat the Workbook as purely an interface, and move the code to the
Access database and have it accept the Workbook as a parameter if
needed. The advantage would be the code could be maintained in one
place (Access), but it would have two main disadvantages. Each user
would need to have Access installed in order for it to instantiate
the application to call methods on, and it would lock in your
"interface" - that is, changes to how it calls Access macros would
still require Workbook updates.
Create a canonical Workbook and have the user Workbook version check
against the canonical Workbook when opened. If the version is
different, open the new one, move all of the data to it, delete the
old one, and save the new copy to the same filename as the old one.
The main disadvantage of this method would be ensuring that old code doesn't run might be difficult, as you would need
to take measures to prevent situations where the user could abort
the update process and still have a working copy of the old code.
Automate the VBE (see this answer for implementation details -
there are numerous resources on how to do this). Depending on how
you wanted to do this, you could either store the current modules as
files and import them, or store the code in the database itself and
query for it. The main disadvantages of this method are that the
VBE can be fickle about changing code that is actually running. I'm
not sure that I'd trust it to change it's own implementation. You
would also need to allow access to the VBE in each user's security
settings, which may pose a security threat.
Store the location of the Workbooks themselves in the database, then
push out updated copies with external code. The Workbook would
report it's filepath when opened, and if it wasn't already recorded
in the database, check to see if it was the most current version,
and then write a record for itself. This has the disadvantage of
only being able to inform the user that they don't have the current
version if they (for example) move the Workbook in Explorer and
don't open it until after your push.
Note that these are all "pull" type as opposed to "push" type solutions with the exception of the last one. Regardless of the method you use for version checking, any push solution is going to share the disadvantage of number 4 - there is no reliable way to make sure that a push catches all the invalidated versions.