I created a directory using SQLPlus console but I cant find it on file system. Here is the command I used:
SQL> create directory secfile as ’/opt/oracle’;
Directory created.
I have looked in my Oracle home directory(C:\Program Files (x86)\Oracle) but there is no 'images' folder.
Where should I look for it?
I'm using Oracle 11g Data Base(installed on my C drive) and I need this directory to store pictures which I will be further storing in the data base. I was following a tutorial about storing pictures on OracleDB in which ’/opt/oracle’ patch were used for that directory.
You have things the wrong way around. You need to create a directory in the operating system, and then create an Oracle directory object using the full path to the operating system directory. The Oracle create directory command only creates a data dictionary object, it does not itself do anything on your server's file system. And you can't use a relative path.
Well, you can create them in either order, but the operating system directory has to have been created by the time you try to use the Oracle one, so to me it makes more sense to create that first.
The CREATE DIRECTORY command does not create a directory on your server's disc. It creates a directory object in your Oracle database which serves as a "pointer" (if you will) to a directory on your disc, and until some code running in your database (for example, some PL/SQL code) tries to use the directory object the database will not know or care if the directory actually exists on the disc. YOU have to create the disc directory, using either Windows Explorer or the Windows command line.
Best of luck.
Related
As I don't see a parameter for a directory like impdp, where does imp search for the dump files that are specified by the FILE parameter?
I've searched through the Oracle's documentation for the original import utility and I don't see anything that says where it searches for the dump files.
Original Import Documentation
imp is an operating system utility and is invoked from operating system command prompt. By default, it searches for the file in current directory (the one you're in while running the imp executable).
If you specify the path to the file, then it is obvious.
If you used more recent Data Pump Import, then you'd have to specify the directory parameter which points to a directory, Oracle object that points to a file system directory. It is usually located on the database server. Directory (the Oracle object) is owned by SYS who then grants read and/or write privileges to database users who will be using that directory.
Everything above means that: imp can use dump files locally, while - for the Data Pump utilities - you don't even have to have access to the physical directory; someone else (such as a DBA) might manipulate files, put them into (filesystem) directory so that you could use them.
I have a ddl script to create some tables but the data is in .ctl files and I never use it before. I did some researches but I didn't quite understand how to use SQLLDR. How it works? Can I use some other way to execute the .ctl file? I'm just using PL/SQL and Oracle 10G
The way you put it, it would go like this:
using DDL script, create all those tables
if CTL files contain data, I presume it is within the BEGINDATA section. Fine, couldn't be better because - as soon as you run the loader, it'll know where to find data to be loaded (it also means that control file uses infile *, right?)
you have to have access to SQL*Loader
if you can connect to the database server, it is there
if you're using your own PC, see whether it is installed
along with the Client software
or, you might even have a database on your PC (XE?)
once you have it (the sqlldr.exe), make sure its directory is contained with the PATH environment variable, or - if not - invoke it by specifying the whole path to it
open command prompt of your operating system
navigate to directory that contains CTL files
run the loader as
sqlldr scott/tiger control=file1.ctl log=file1.log
If everything is OK, data will be loaded. Check log files!
Is it possible to append/remove a ressource file to a binary at execution time?
I have an application written with go, which saves/searches data from a database file, and i would like this database file to be embedded to the binary, and updated by the application itself.
This way the application would be self contained with its database.
Modifying the executable, this is generally a very bad idea.
Several issues pop right into my head, such as:
Does the current user have sufficient permissions?
Is the file locked during execution?
What about multiple running instances of the application?
Even if you manage to do just that, think of what anti-virus and firewall applications will say to it: most when they detect the change will flag the executable and/or contain it, or deny running it, or some may even delete it. Rightfully, as this is what many viruses do: modify existing executables.
Also virus scanner databases maintain reports where files (their contents) are identified based on the hash of their content. Modifying the executable will naturally change the file content hash, thus render the file unknown / suspicious to these databases.
As mentioned, just write / cache data in separate file(s), preferably in user's home folder or in the application folder (next to the executable, optionally in sub-folders). Or make the cache file / folder a changeable option (command line flags).
Technically, this is possible, but this is a bad idea. Your application could be run by users not having write permissions to your binary.
If you're talking about a portable app, your best option might be using a file in the same directory the binary is located, otherwise - use the user's home directory according to the conventions of the OS you're running on. You can use the os/user package to find the home directory.
As pointed out in Writing config file in C:\Program Files (x86)\MyApp\myapp.cfg, vs. Administrator privilege, it is not a good idea to write a config file in C:\Program Files (x86)\MyApp\myapp.cfg.
Instead of this, my software now saves its data in a subdir of %ALLUSERSPROFILE% (ex : C:\ProgramData\MyApp\myapp.cfg on Win7)
[I use myfile = open(filename, 'a') in Python to do this.]
I now encounter an issue about this file :
I installed the software with User A, and ran it, then the file C:\ProgramData\MyApp\myapp.cfg was written.
Then, I changed user to User B, and ran my software again : now an error is displayed : User 2 has no right to write in C:\ProgramData\MyApp\myapp.cfg (Permission denied).
Why? Isn't %ALLUSERSPROFILE% a place that can be written by all users?
How to solve this problem ?
No, C:\ProgramData, aka FOLDERID_ProgramData, has restricted security settings. Standard users can create files there. But these files are, by default, secured so that only the user that created the file can subsequently modify the file.
The recommended solution is for your installer to create a sub directory of C:\ProgramData for your shared storage. And that sub directory must be given a permissive ACL by the installation program. That is what grants the desired access to all standard users.
I do wonder whether you really need shared writeable data. Normally I'd expect to see shared configuration be something that is specified at install time and modified infrequently by administrators. Most configuration data tends to be per user.
I'd like to add onto this as I was having issues writing to C:\ProgramData as well. My issue ended up being that my directory/files within C:\ProgramData were written by an administrator. When my app ran under a normal user it was unable to write there so Windows automatically used C:\Users\fooface\AppData\Local\VirtualStore\ProgramData instead. I found the path it was writing to by using process monitor on my application. After seeing this I deleted the files out of C:\ProgramData and ran my app again and it wrote there as expected.
Hope this helps someone.
I have an old update program written in vb6, which runs as admin. However, because it runs as admin, all the files it downloads and saves are read-only to other users. Even files in public places like the shared application data folder (which is where I'm saving the files in question).
I'm lucky I found this before the 'vista-compatible' release. Vista hides the problem by redirecting non-admin writes and future reads to a sortof 'virtual' folder. But the next update may replace the file, and the non-admin program will still go to the virtual folder and use the old file.
As the admin user, how do I allow other users full control of files I write in vb6?
The way I do this is to make it an Installer responsibility.
Use VSI 1.1 to create an Installer MSI for your application. Create an application data folder under CommonAppDataFolder.
As a post-build step run a script to perform the following:
Set the MSI database for a per-machine installation: Property table, row with ALLUSERS set to 1.
In the Directory table, locate the entry for CommonAppDataFolder and obtain its directory Index. Use this Index to query the Directory table for an entry where CommonAppDataFolder is the parent and obtain its Index (this is your app data subfolder).
Look in the File table to obtain the component Index of your program.
Create the CreateFolder table in the database if it isn't present. Add a row to CreateFolder for the desired application subdirectory by its Index, tying it to your program's component Index.
Create the LockPermissions table if it isn't present. Insert a new LockPermissions row for your application data subdirectory, giving it FILE_ALL_ACCESS for Everyone.
That's about it.
You can do it this way, or use VSI 1.1 and then edit the MSI using Orca, or probably by using a 3rd party MSI authoring tool these entries will be settable via its GUI and can be saved in the Installer project. I just use a small WSH script I run after each VSI 1.1 build.
AFAIK this is the recommended way of accomplishing such things according to Windows application guidelines. If your needs are fancier you might use multiple subdirectories or sub-subdirectories some allowing full access, some read-only, etc.
Your program can locate the folder using Shell Automation objects or by calling Shell32 as a standard DLL (using Declare Function or a TLB).
It's not necessarily who writes the file, but where they write it to. The program files folder and it's sub folders are read-only to all standard users by default. Try using the All Users Application Data folder instead.
This is a little tricky for VB6, since it was not at all designed with Vista in mind. Some of the relevant folders were re-named and there's no way I know to get vb6 to give you the exact folder you want short of using a "Declare Function" alias to call directly into the windows API.
So the easiest reliable way I know to find a suitable location is to use the %ALLUSERSPROFILE% environment variable. That returns "C:\Documents and Settings\All Users" by default on XP and "C:\ProgramData" by default on Vista. From there you can look for an "Application Data" folder. It won't be there and you don't need it on Vista, but creating one if it doesn't exist won't hurt anything. That gives you a consistent folder structure on both systems from which you can create a sub folder for your app to use as a work space.
And one final note: this isn't a new change for Vista. Program Files folders have always been read-only to standard users by default. XP worked the same way. It's just that so many people run as administrators in XP you might be able to get away with it.