I cannot access my system environment variables from my administrative user account. I am still able to access my user environment variables though. When I try to access SystemPropertiesAdvanced.exe from the Control Panel > All Control Panel Items > System > Advanced system settings, I get an error: "Windows cannot find %windir%\system32\systempropertiesadvance.exe"
From a cmd window, I entered "echo %windir%" and it wasn't set. After that I entered "set" and saw only user environment variables. I navigated to: C:\Windows\System32 and ran SystemPropertiesAdvanced.exe. This worked and I saw my complete list of system variables, but I'm wondering if there is a setting I can adjust which will allow my user account access to the system variables.
Go to C:\Windows\System32\ and find SystemPropertiesAdvanced.exe.
Start the program and click on Environment Variables button.
Then add new (Name: windir, Value: %SystemRoot%) to system variables.
I think I did have access, but the problem was that my user and system %PATH% variables were different. I'm not sure, but I think the user variables are used before system variables. I compared the values of user vs system and my user variable was much smaller. With this I concluded that it mush have been trying to access the wrong variable. Now I don't get the error messages anymore.
Related
While developing transformations on local I set my transformation path to the target folders that are presented in Local PC and Once testing is completed on local I am moving our transformation to server repository to schedule it from server environments but every time I require to change the path set to the server folders. I believe it can be done by creating dynamic path or creating any variable but I am unable to resolve it. Is this option available in Pentaho? if Yes, Can you please help me for setting the dynamic path?
In This answer there is a link to a described solution, and in the answer i have a sample KTR that should help.
You can also use the pentaho properties file in different environments, meaning, you can utilize the same variable in both environments, say ${path}, but in each environment this has a different value.
kettle.properties can be found in your user folder .. C:\Users\YourUser.kettle
The standard way to handle environments in Kettleis with variables.
In the home directory there is a (hidden) folder named .kettle which contains every thing that should be local : your preferences, your shared connections, your cache, and, most of all, THE kettle.property file.
You can define variables in it, like a ${myPath}. To do this, use the menu Edit/Edit the Kettle.properties and add a variable named myPath and give it for value your prefered path, with an optional description.
Then, when you see a blue diamond with a $ on the right of a field in a step window (which means almost any field you'll need), you can press Crtl+Enter in the field and choose any variable defined in your kettle.properties. Alternatively, you may type or copy/paste ${your-variable-name} in the field.
Then, when launching spoon, it will not use the hard-coded path, but the content of the variable in the kettle.properties.
And nothing prevent you from having a different kettle.properties on your dev PC and on the prod server.
While we are there, three usefull tricks.
There is a predefined ${Internal.Job.Filename.Directory} variable contaning the path of the current transformation which by used for relative path. For example, ${Internal.Job.Filename.Directory}/../myDir/myFile.ext.
If you right-click anywhere on the screen, and go to the Properties/Parameters, you may also define your variable here.
You may also redefine these variables in the Run Option window that anoys you each time you rune a transformation (yes, there was a reason).
Finally, you can send these variables from job to jobs and transfos.
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.
I've been trying for a while now to get a reference file to be loaded externally to no avail.
To be specific I am trying to load a "Microsoft Date and Time Picker Control 6.0(SP4)" which usually resides in C:\Windows\System32\MSCOMCT2.OCX
However some people that run a macro containing this element don't have that "MSCOMCT2.OCX" file on their PCs so I thought I will move the MSCOMCT2.OCX to a shared location and reference the code to use the shared one instead (so everyone will have access to it)
I tried doing that but when I was trying to load a reference with "Browse" from a different location it didn't load it - because I already had that in C:..
So I thought OK... I will remove the file from C:\ so I can only reference the shared file. - so I deleted it.
So I open the workbook again and look at references - I cant find "Microsotft Windows Common Controls-2.6.0(SP4)" - great!
And I proceed to add it manually with Browse from the shared drive.
When I do that however 2 references of "Microsotft Windows Common Controls-2.6.0(SP4)" are being added - 1 from C:\(which is not there) and 1 from the shared drive.
The one from C:\ is always automatically selected.
If I try to disable the one from C:\ and enable the one from the shared drive it automatically changes back to what it was when i press OK.
If I try to enable both - it says duplicate References and keeps only the one from C:\
So.. does anybody know how can I get rid of that C:\ reference from the list so it doesn't get loaded? Apparently deleting the files themselves did not work.
Ultimately my goal is to enable people without C:\Windows\System32\MSCOMCT2.OCX file to be able to use my Date Picker Tool.
Thanks a lot!
ActiveX control rereferences are always GUID-based. The VB IDE shows you the current location of the file as listed in the registry on your computer, as a courtesy, but it really doesn't matter what it says. The control will be loaded from wherever it was registered on the user's computer.
That's the key: the control must be registered on the user's computer.
I must strongly discourage you from doing what you're trying to do. You might be able to concoct a method by which you load the DLL from a network location, but it presents no advantage over doing the Right Thing(TM), and plenty of problems. The Right Thing is simply that if you need that control, you must distribute and register it with your application, just like everybody else does. And you really should install it in the recommended location for it (System32); not on the network.
Here's a quick example of what can go wrong: you provide your user with you app, and it works with the control on the network like you want it. Then the user installs another application that happens to need the same control. The app's installer sees that the control is already registered on the user's computer, so it doesn't try to add it again. Except that this particular app is intended to be used when the user is not connected to a network. Now you just broke someone else's program.
The VB/VBA architecture was never intended to support XCOPY deployment. I'm know it's a pain and that these extra steps are extremely inconvenient when you're just trying to deploy a "macro". Sadly, it's the nature of the beast. I'm sorry
I need the heap to be verified each time the garbage collector (GC) finishes its work. I read this can be done by setting the environment variable COMPLUS_HeapVerify to 1. But how exactly do I set this variable?
I read this can be done via Computer/Advanced System Settings/Advanced/Environment Variables (Windows 7), somebody tells I should set up a new system variable (here), others tell this should be a user variable (here).
Is this approach correct and which (system or user) variable should be set?
The approach you mentioned is absolutely correct.
Go to Control Panel->System Properties->Advanced System Settings->Environment Variables.
If you have administrator privileges, add a system variable called “COMPLUS_HeapVerify” with a value of “1”; otherwise — add the user one. Note, in the second case you might need to log out and log on.
Hope that helps.
While opening any MS Access database, a security warning appears saying that the file can be harmful to the computer. However, is there a way to remove this message. Or should it remain a necessary evil
You can probably sign your program. I don't know for sure. Read this article and see if the same principle applies.
If you lower the security settings in your Access options it will go away I believe. Of course those settings are set where they are for a reason.
Here are some more notes on certification and security.
Certification, including self-certification:
http://office.microsoft.com/en-us/access/HP010397921033.aspx
General information on security principals for Office code and macro security: http://office.microsoft.com/en-us/ork2003/CH011480831033.aspx
Trusted location defaults for Office 2003
http://office.microsoft.com/en-us/ork2003/HA011403181033.aspx?pid=CH011480851033
Macro security in Office 2003
http://office.microsoft.com/en-us/ork2003/HA011403071033.aspx?pid=CH011480831033
You can eliminate the security warning at the startup of a ms-access project by putting the access project in a Trusted Location. Or Better yet, make your own Trusted Location.
I recommend creating a folder in the System (C) drive with the name of your project. For example, we could call the folder Database (Path: C:\Database)
Then enter this path as a registry key like this:
[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Access\Security\Trusted
Locations\Location20] "Path"="C:\Database" "Description"="Access
Project location"
Now lets explain a few things about what this key did:
The number "14.0" is the version of MS Office. You can simply change that to the number that represents the version you are running.
The "Location20" is a unique name that we assigned. The 20 can be any number that is not already used. Other programs, including default MS Access wizards, already may have used other numbers. Or if you want to make more then one path as a trusted location, then each location must end with a different number.
The "C:\Database\" actually is the physical path that you want to set to be a Trusted Location. You can put any path that you choose here. I am not sure why it uses double \, but I just copied the example of how the previous keys were set up and this seemed to work best.
The Description is not needed, but obviously any description can be used.
For more details on how to make Trusted Locations work for your MS Access project, read our detailed explanation here: http://blog.ideaz.net/2013/12/how-to-remove-microsoft-access-security.html
Here's my notes from a similar, internal issue with Access 2003 a few years back:
Okay, so here's (evidently) the deal.
The network server was not in the Trusted Zone. Starting, IIRC, with SP2, this causes a Open/Save/Warning box when opening a file. By default, UNC paths are supposed to be in the Trusted Zone. I'm not sure why it wasn't, but here's the fix: Add server.dns and server to Internet Options->Security Zones->Local Intranet.
Unsafe Expressions Are Not Blocked. This is some ridiculously overcomplicated Access security model (Google for unsafe expressions and Access Sandbox Mode for more). Basically, Access (starting with 2003 and/or Jet 4.0 SP8, I think) warns you if a registry key is not set to disallow "unsafe expressions". The fix: Set HKLM\Software\Microsoft\Jet\4.0\Engines\SandBoxMode to 3, which blocks "unsafe expressions" for anything using Jet. This has to be done by an Administrator. Alternatively, I think that answering "Yes" to the Block Unsafe Expressions prompt as Administrator sets that key for you.
This file may not be safe to open. This is an easy one, and follows the whole macro security model in Office. Just set the Tools->Macro->Security (don't look in the Tools->Security menu...that'd be too obvious) to Low.
BTW, I still have no idea what an "unsafe expression" is - nor why it continually asks to upgrade to Jet 4.0 SP8 when it already has been (I verified that it was updated by checking the file versions). But with those changes, it no longer asks anything when starting up. --MB
In Control Panel, click 'Internet Options'.
In the 'Internet Properties' popup, select the 'Security' tab.
Select 'Local Intranet' zone.
Click 'Sites' button.
In the 'Local Intranet' popup, clear the "Automatically detect..." checkbox and set the following checkboxes:
"Include all local (Intranet) sites not listed in other zones"
"Include all network paths (UNCs)"
'OK'.
'OK'.
Now all Access dbs anywhere on your Intranet or any referenced by a UNC will open immediately without warning. You assess the convenience/security tradeoff.