In Windows, what are the built-in options to store config data (any data) locally?
I see three categories at least:
Files (such as .txt, .ini, .xml etc)
ODBC
Registry
Anything else?
I want to know if there are any other options.
Let's say you installed a software and you want to know where it is referencing for its own config data, where can we look for?
FYI:
OS: Windows 7 64 bit English version.
That's pretty much your options, but I have to pull you up on number 2. ODBC is not a location in which you can store data; it's a technology by which you can access data. An application interacts with an ODBC driver and then that driver interacts with a data source. That data source will most often be a database of some sort but certainly not always. I think what you actually meant to say was "database", which may or may not be accessed via ODBC from an application.
Am not sure that, this is what you need.
Click Start, point to All Programs, and then click Accessories.
Right-click Command Prompt, and then click Run As Administrator or Start-> Run-> cmd.
Type bcdedit at the command prompt
please refer this link for more info: http://technet.microsoft.com/en-us/magazine/ff404185.aspx
Related
Per
http://www.accessmvp.com/djsteele/DSNLessLinks.html
I've attempted to replace DSN-created table defs in Access with a DSN-less connection.
No luck trying the driver from Microsoft:
Microsoft ODBC for Oracle
because of this specific issue:
https://support.microsoft.com/en-us/kb/942976
On Windows 7 64 bit, you have to manage the ODBC driver (DSN) using the 32 bit ODBC Admin panel, if you want to use Access 2013 32 bit.
However, that doesn't solve the issue because I'm trying to go DSN-less in the first place.
I assume that the reason the connection doesn't work is that Windows is "helpfully" choosing the 64-bit version of the driver when I use this as my connection string:
strConnectionString = _
"ODBC;DRIVER={Microsoft ODBC for Oracle};" & _
"Server=" & ServerName & ";" & _
"UID=" & UID & ";" & _
"PWD=" & PWD & ";"
The issue is I can't specify that I want the 32-bit version of the driver, because both versions (32 and 64) have the same name.
Is there a way around this?
Thanks,
Chad.
The location of driver you can check in your Registry. In case of x86 (32 bit) check HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI\Microsoft ODBC for Oracle\Driver. Most likely the value should be %WINDIR%\system32\msorcl32.dll
Now, in case you run a x86 application like your MS Access folder %WINDIR%\system32\ is automatically redirected to %WINDIR%\SysWoW64\ (see WoW64), so you (or MS Access) will find file msorcl32.dll in folder c:\Windows\SysWOW64\.
In principle for x64 you would have to check Registry value HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Microsoft ODBC for Oracle\Driver, however Microsoft ODBC Driver for Oracle is deprecated and available only for 32 bit! In case you need a 64 bit version you have to download and install ODBC driver from Oracle.
Your 32bit Access should work without any problem using 32 bit ODBC drivers.
There is no confusing issues, since an “in-process” x32 program will only load and use the x32 driver. And an “in-process” x64 bit program will only load and use the x64 driver. They both can have the same name, but they are installed and in different locations on the OS.
And if you read your linked articles, the simple solution is to always launch the correct version of the ODBC manager. And the simplest way to do this is to create the link from inside of access since access will ALWAYS launch the correct ODBC manager.
And at the end of the day, since you using DSN less, then this further means the links you use have zero to do with your question and issue.
So while the drivers might have the same name, the OS and software can ONLY use the same bit size software and thus that what will be used in your case.
The only issue you want to check is while in Access you want to launch on the external data tab from import and link the ODBC manager. At that point you link a single table to oracle using that manger and then access will grab (copy) that connection string. And you note that if no oracle driver is displayed, then you have to install the oracle driver (but likely the oracle driver already exists).
Then AFTER verifying that the link works, then simply hit ctrl-g to jump to the debug window, and display the connection string setup with this command:
? currentdb.TableDefs("table I just linked").Connect
You then see the connection string used, and the name/syntax of the oracle drive will be shown – that’s what you use in your connection string.
I should also point out that when launching the ODBC manager from Access the “default” tab is “File data source” – this will ALWAYS create a DSN less connection in Access. So Access by default will always use and create a DSN-less connection. The File Data Source is ONLY used at create time. Once you created the linked table then you could for example move the database to a different computer and the table link will continue to just work fine due to Access using DSN links by default (so the information is “copied” to the table def connection string for that linked table – the original file data source from that point on that you saved via the ODBC panel is ignored and not used.
Bottom line:
All those links to those articles don’t matter and are NOT your problem or issue. You simply have to create a linked table using the GUI in Access to oracle. If that works, then simply look at the connection string for that linked table as per above and it will show/display the correct driver string you need to use.
Here's the issue and how it was solved:
Legacy system that started probably in Access 97 (.mdb) that is currently in Access 2013 (.accdb) format. (We aren't budgeted to re-platform the system until next year)
There are hundreds of linked ODBC tables to Oracle data sources, only a handful of which are actually used. Only 15 tables were either being used directly or being subsequently linked by other .accdb databases.
The root of the problem was that four of the tables had been created using either a now missing DSN, a missing or out-of-date user id, or a bad password.
Users would see the "ODBC link failed" message during one of their processes and have to go to linked table manager and puzzle through the names of the tables to figure out which ones to re-link. (Usually they'd select all 200 of them).
Then they'd get prompted to update the DSN/UID/PWD.
Of course when doing that, Access 2013 doesn't save that information to the tabledefs... so every time the users would try to run their processes again, they'd see the ODBC failure message again.
The solution was to drop and re-add the four linked tables with the up-to-date DSN.
I also added a button for them on the main form that went through the shortened list of ODBC linked tables (only 15 of them) and ran TableDef(_TABLENAME_).RefreshLink on the table def for them.
Thank you to both Albert and Wernfried for the insights.
(I'm hoping to be part of the team that replatforms the system to exist all in SQL Server and/or Oracle (backend) with the front end in HTML 5 next year, so this was a good stop gap).
I have a very simple question. After installing Informix (iif.12.10.FC2DE.win2003.zip) on my computer, the database system seems to be running.
How can I access it? I even installed Server Studio (serverstudio_w_sentinel_win_9.1.10397.zip), but all frontends ask for so many things (what is the difference between host ans server, btw), and I don't know what to enter.
I have a lot of experience with HP-SQL, Oracle and PostgreSQL (all on Unix/Linux). In PostgreSQL, you just enter psql on the command line as the user postgres and create users and databases.
There is a bit of a missing link. Can anybody help me with this? Unfortunately, the computer runs Windows 8, so there is no helpful Start Menu.
Thanks in advance!
I never installed Informix at Windows 8 , AFAIK should not be different of any other windows.
First, as common knowledgment the "pre-configured" and basic access to Informix database is with an utility called dbaccess , you can compare it with sqlplus from Oracle, mysql from MySQL and psql from Postgre.
It run only in CUI mode, but something as "ncurses like" based on menus (it isn't by self a command line like the others mentioned)
So, answering the question , to start the basic access with dbaccess you should open the Informix Command Line which is a shortcut what should have been created during the installation at you windows Informix Apps Menu.
Logged with Informix , at Start menu, you should have access to Apps menu clicking at the lower arrow at the bottom of the screen.
Look for Informix command line icon, it's a shortcut to .bat very specify to your instance configuration, this file will define the informix environment variables (INFORMIXSERVER, PATH, etc) and open the prompt to you.
Then just type dbaccess and voila , there is...
At windows 7 you need run this command line as administrator (right click on icon and choose the administrator option). Not sure if Windows 8 is the same...
Basically that's all...
But I always see windows users "up theirs noses" to dbaccess because it isn't friendly for a windows user, since it run at command line and windows command line is very limited if compared with any *nix shell.
Now if you ask for any informix user at Unix/Linux world the history is different...
So, alternatives graphics tools to access Informix like DBeaver, ServerStudio, SquirrelSQL, DbVisualizer, etc... you must know some configurations of your instance:
Looking from client point of view, for a TCP/IP connection, you must know :
INFORMIX SERVER : Is the name of your instance/engine (not database) and is directly associated to the instance listeners.
One instance can have multiples names (listeners) and one machine can have multiple instances running simultaneously. At basic install and with auto configuration you probably will found only one name, something like ol_#####.
For oracle this is similar of ORACLE_SID .
if you open your Informix command line, you can discovery this typing echo %INFORMIXSERVER%
HOSTNAME : The hostname/IP of the machine where is the engine.
This can be the localhost/127.0.0.1 but depends if it was configured ant the listeners of the engine. Probably will be the hostname of your windows..
SERVICE NAME : this is the network service configuration / port number for TCP/IP listener.
This can be a number or the name, if you use the name, then you need configure the services file. Probably you will find it at: c:\windows\system32\Drivers\etc\services
PROTOCOL : There a few options here, but by default use the onsoctcp, unless you configure/choose other like Data Driver (DR).
DATABASE NAME : This is will be the default database used by the connection, if you don't have anyone set to "sysmaster" which is the mainly database of the engine.
but don't play with it! it is like SYS/SYSTEM database for Oracle...
USER/PASSWORD : By default Informix uses OS authentication, so only users which exists at Windows will able to login at the database (of course, they will need the grants to access databases, tables, etc).
This is a connection string for a JDBC client (like SquirrelSQL) :
jdbc:informix-sqli://<host_name>:<port_number>/<database_name>:INFORMIXSERVER=<server_name>
If you like to know more information about the network configured at your instance/engine check this :
SetNet32 : the utility specify for Windows which configure the listeners used by the engine.
(this is only for windows where they use windows registry to save the information. At *nix world is used the $INFORMIXDIR/etc/sqlhosts file or any other pointed by $INFORMIXSQLHOSTS file).
ONCONFIG : the mainly configuration file of your engine, located at %INFORMIXDIR%/etc/onconfig.%INSTANCENAME% .
inside it, look for DBSERVERNAME, DBSERVERALIASES
For more information you can look at online informix Manual : http://pic.dhe.ibm.com/infocenter/informix/v121/index.jsp or download the PDFs (you will find the link to download at the main page of this link)
DBeaver and SquirrelSQL
This tools are FREE Java I-SQL where both works fine with Informix.
DBeaver have an advantage , it's automatically download and install the JDBC driver for you.
For SquirrelSQL you need setup it manually (but isn't hard).
When you install informix there is an option for install default instance and at the end you can choose if want start it and open command line or not. If you select yes a command line will be prompted and you'll can access to bin folder and type
dbaccess.exe
(bin folder usually is in your informix instalation folder)
Now you can manage your informix server.
If you want create your own instance you'll can't execute dbaccess -at least you open the correct command line-. To open the correct command line you need access to your instalation folder and execute the cmd according your instance, for example myinstance.cmd, this will open a command line and now you can go to bin folder and execute 'dbaccess.exe'.
This is a very very high exaplanation but it seems to be usefull for my team.
If you need more info the #ceinmart anwer is awsome, or:
http://www-01.ibm.com/support/docview.wss?uid=swg21651873
https://www.ibm.com/support/knowledgecenter/en/SSGU8G_11.50.0/com.ibm.igmsw.doc/ids_iw_020x.htm
I am running a VB 6 application for a report. It prints well in local with System DSN. But when i put the .exe of the application in RDS , report is not printing for System DSN rather its printing for User DSN. For System DSN its showing- "Cannot open SQL server".
My Efforts-
1.
http://social.technet.microsoft.com/Forums/windowsserver/en-US/bb2ced17-9dd3-40e4-b5b6-dd773ee7001c/system-dsn-on-rds-server
I tried with creating a 32 bit DSN using [WindowsDir]\SysWOW64\odbcad32.exe, but wont work out for me.
2.http://www.tek-tips.com/viewthread.cfm?qid=341776 I tried to change the permission of the System DSN as logged in as Administer and to give full permission for the user using regedt32. But still the same error as "Cannot open SQL server".
But as soon i create User DSN, it works fine. Please help.
If this problem is due to "stale" incorrect virtualized System DSNs that have been created for one or more users then changing the real System DSN won't matter. Programs that run in legacy mode for these users will keep seeing their virtualized copies.
System DSNs are stored under:
HKEY_LOCAL_MACHINE\Software\Odbc\Odbc.ini\Odbc Data sources
... but virtualized entries end up under:
'HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software\Odbc\Odbc.ini\Odbc Data sources
... according to Registry Virtualization.
So to clean the virtualized registry entries out (delete them) to unmask the real DSN could be a lot of registry fiddling. You might do this most easily by creating a script or small program that gets run once under each corrupted user ID.
Or just reformat the boot drive and reinstall Windows!
This is without even going into possible issues around WOW64 registry redirection, a different though similar problem. Why not just stop using creaky old clumsy ODBC? Are you really using it on purpose?
The ultimate fix (after cleaning up the machine) is probably:
Stop using DSNs at all. They've been deprecated for a long time which is why we have DSN-less connection strings. These are easy and safe to store in places such as INI files when hard-coded connections are not practical. We've also had UDL files for ages now.
Deal with the appcompat issues in your programs and then add manifests to them so that they run in "UAC aware" mode instead of legacy mode. This prevents such confusing and hard to fix mishaps.
Many questions on SO say "Windows developer guidelines" or "windows design guidelines" say that you shouldn't write temporary or program data to the Program Files area, but as far as I can tell none of them actually link to a piece of documentation that says as much. Searching the MSDN has yielded me no results. Windows will make the area read-only, so it can be enforced by the OS, but that doesn't mean developers didn't try to write there anyway (e.g., when porting older, XP and earlier based programs forward.)
I realize that it seems odd to ask about it this late into Windows development (since, as a commenter below pointed out, has been enforced by the OS for more than a decade), but a document that says so is sometimes necessary to satisfy people.
With that in mind, Does Microsoft have a document published stating we shouldn't write application data to the Program Files area, and if so, where is it?
From Technical requirements for the Windows 7 Client Software Logo Program:
Install to the correct folders by default
Users should have a consistent and secure experience with the default
installation location of files, while maintaining the option to
install an application to the location they choose. It is also
necessary to store application data in the correct location to allow
several people to use the same computer without corrupting or
overwriting each other's data and settings.
Windows provides specific locations in the file system to store
programs and software components, shared application data, and
application data specific to a user:
Applications should be installed to the Program Files folder by default. User data or application data must never be stored in this
location because of the security permissions configured for this
folder (emphasis added)
All application data that must be shared among users on the computer should be stored within ProgramData
All application data exclusive to a specific user and not to be shared with other users of the computer must be stored in
Users\<username>\AppData
Never write directly to the "Windows" directory and or subdirectories. Use the correct methods for installing files, such as
fonts or drivers
In “per-machine” installations, user data must be written at first run and not during the installation. This is because there is no
correct user location to store data at time of installation. Attempts
by an application to modify default association behaviors at a machine
level after installation will be unsuccessful. Instead, defaults must
be claimed on a per-user level, which prevents multiple users from
overwriting each other's defaults.
And I'm quite sure that there's similar stuff for every Windows version of the NT family going back to Windows NT 4 or even earlier.
See also this question.
Edit: the original link in this post to the Windows 7 Logo program exists no more. Here you find the current link to the Certification requirements for Windows Desktop Apps. See Section 10, Apps must install to the correct folders by default
In later versions of windows (Vista, 7 and of course server versions) access permission are restricted for "special folders" including "Program Files". Even if your program is elevated to have sufficient privileges to write to this folder it is still a bad idea.
I don't know of any guidelines that state this but there is a list of special folders and what they are meant for. The fact that there is a special folder for nearly all types of data I can image means there is no need to use the program files folder.
We have an application that stores its database files in a subfolder of the Program Files directory. These files are redirected to the VirtualStore in Vista and Windows 7. We represent data from the database using Microsoft DataReports (VB6). So far so good.
But we now want to use Crystal Reports XI to represent data from the database. Our idea is to NOT pass this data to CR from our program, but to have CR retreive it from the database using a a system DSN through ODBC. In this way we hope to present our users with more flexibility in designing their own reports. What we do want to ensure though is that these system DSNs are configured correctly when the user installs our program or when the program calls the Crystal Report.
Is there a smart way to do this using System variables for instance, instead of having to write a routine that checks for OS-version, whether UAC is enabled on the OS, whether the write restrictions on the Program Files folder have been lifted, etc and then adapts he System DSN to point to either the C:\Program Files\OurApp\Data folder, or the C:\Users\User\AppData\VirtualStore\Program Files\OurApp\Data folder?
Suggestions for an entirely different approach are welcome too!
New applications should have an application manifest that specifies requestedExecutionLevel. This declares your program "Vista aware" and bypasses attempts at virtualization.
During installation you should create a folder like [CommonAppData]\Company\App\Full and set security on this folder to allow Full Access by Everyone (or by Users). Put your database into this folder.
For an MDB you can drop the database right here. For a client/server database put a UDL file here. Also see Use Universal Data Link (.udl) Files.
ODBC and DSNs are pretty obsolete technologies.
Using the suggested approaches should work for almost anything but the oldest Win95 computer.
Is this an Access database? You haven't specified.
For an Access database, you don't need to point your DSN to a specific database when you install it. You can modify the connection string to point to different databases at runtime (details). For instance
Driver={Microsoft Access Driver (*.mdb)};Dbq=C:\mydatabase.mdb;Uid=Admin;Pwd=;
Can you simply read the installation path at runtime (in VB6 it is App.Path) and then send a different connection string to Crystal Reports?
It seems that Virtual Store takes care of everything, so you can point the DSN blatantly at C:\Program Files\MyApp\Data\mydb.mdb even while the database has been relocated to the Virtual Store.
Current Version
You might want to detect the current-version of Windows the system is running.
This will in turn help You in determining the correct PATH.
How to find windows version, build and revision numbers??
Read the the Registry keys –
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentBuildNumber
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\EditionID
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProductId
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\BuildLabEx
The CurrentBuildNumber is your Windows Build Number. Then CurrentVersion value is your windows version i.e. the version of your windows 7, windows vista, windows xp, etc. EditionID and ProductId to know the windows-edition and product-id.
The key BuildLabEx contains build number and revision number.
For example, in the value 6001.17387.x86fre.vistasp1_gdr.070927-1921:
the first four digits stand for build number i.e. 6001 and
the next five digits stand for windows revision number i.e. 17387.
x86 tells you that you are running a 32-bit operating system.
You might also be interested in this:
How to detect true Windows version?
GoodLUCK!!