I love Oracle SQL Developer so I find myself using it a lot to complete my daily tasks. The thing is that my collection of custom snippets only keeps growing so I though it'd be interesting to learn how to backup them.
Before asking blindly I did a bit of work trying to figure out how. I've performed a search within the application's folder by "snippet" and found the following file:
oracle.sqldeveloper.snippet.jar
which quite probably contains my beloved pieces of code. I could just save that file hoping the best, but why not doing it the right way and perhaps being able to, say, only backup the ones and I've created, avoiding the ones that came out-of-the-box, et cétera?
Any suggestion would be really appreciated!
On my WinXP machine, I found my User Snippets at:
C:\Documents and Settings\eddie\Application Data\SQL Developer\UserSnippets.xml
PS: Replace eddie with your username.
Agreeing with Eddie Awad, just copy the xml file. And for windows7 the sqldeveloper User-Snippets file can be found here:
C:\Users[username]\AppData\Roaming\SQL Developer\UserSnippets.xml
If you use SQL Developer on Mac OS X, then the snippets can be found in ~/Library/Application Support/SQL Developer/UserSnippets.xml
Are you running on Windows? Check your "C:\Documents and Settings\\Application Data\SQL Developer" directory for a UserSnippets.xml file, it contains all user defined snippets.
Also, check the online help for "Location of User-Related Information" topic. It has location of files that hold other user defined info.
-Dave
Why not create a package on the Oracle server for daily maintenance that way it's stored with your DB and in your DB backups?
EDIT: I do this and find it even easier to use them later on when performing routine maintenance tasks. Being able to call a packaged procedure is really, REALLY handy sometimes.
Agreeing with Spyder -
C:\Users\[username]\AppData\Roaming\SQL Developer\UserSnippets.xml
is the place. But I only found this after creating my first new Snippet.
After that, I was able to edit the xml to add new snippets and new categories. Once a change is made to the xml, SQLDev has to be relaunched. (And since it's an xml, I'm going to see if I can save it to Git to share amongst my team when I get a minute...)
For SQL Developer 3.2.20.09 on OS X Mountain Lion (10.8.*), the snippet file is located in ~/.sqldeveloper/UserSnippets.xml.
On OS-X Yosemite (10.10.5) I found the current UserSnippets.xml for the current SQL Developer ( Version 4.1.0.19 ) also in
~/.sqldeveloper/UserSnippets.xml
Related
Im working at a new development plattform with PDI installed on it.
The plattform remains stable, but Im struggling with a problem since the moment we started to work on it and is related with the PDI behavour on some Oracle SQL queries. The problem is documented here: https://forums.pentaho.com/threads/53201-KETTLE-and-Oracle-s-NLS_DATE_FORMAT/
The subject of my question is:
I need to change the odbc jar file on /lib folder of PDI folders (change odbc10.jar to odbc6.jar) and I dont know how to do it. It can't be as simple as delete the wrong file and put the new one. I suppose that somewhere on PDI configuration there must be a setting pointing to the wrong odbc10.jar and I must set it with the name of the new driver that PDI must use (odbc6.jar). I'm not sure if this setting is neccesary or not. As I'm not admin on this server, I can´t on my own, change the file and test it, I need to open a IT Ticket and ask for the right department to do it and I dont wan't anyone loose their time with wrong instructions.
I hope you could explain me how to change this driver please.
Please..could any of you guys explain how to do it?
Yes, it's as simple as that. If you don't feel confident, instead of deleting the odbc10.jar change the name to odbc10.jar_old or something like that, so PDI doesn't pick this other version of the odbc jar file, so you have a backup of the file quickly available.
In 2022, the question asked in how-to-prevent-oracle-sql-developer-from-writing-to-appdata-roaming is still a bit of a problem. While the -Dide.user.dir option does allow you to move the SQL Developer directory from %APPDATA%, the application still creates a sqldeveloper directory in %APPDATA% that contains a <version>/product.conf file.
What option needs to be added to move this directory as well? I am using version 21.4.3 of SQL Developer. Thanks in advance for any help you all can offer.
You need to convince SQL Developer that it's not actually running on Windows, but is instead on Linux or a Mac.
Otherwise, SQL Developer is designed to do EXACTLY as you describe/observe.
The -Dide.user.dir doesn't let you move those files per se, it more accurately allows you to mirror them somewhere else.
I was having some trouble bulk-loading records to go faster than what cursor.executemany would allow. I hoped the bulk operations documented with regular MonetDB here might work, so I tried an export as a test. e.g. cursor.execute("COPY SELECT * FROM foo INTO '/file/path.csv'"). This doesn't raise an error unless the file already exists, but the resulting file is always 0 bytes. I tried the same with file STDOUT and it prints nothing.
Are these COPY commands meant to work on the embedded version?
Note: This is my first use of anything related to MonetDB. As a fan of SQLite and a not-super-impressed user of Amazon Redshift, this seemed like a neat project. Not sure if MonetDB/e is the same as MonetDBLite - the former seems more active lately?
Exporting data through a COPY INTO command should be possible in MonetDB/e, yes.
However, this feature is not working currently. I was able to reproduce your problem, i.e. the COPY INTO creates the file where the data should be exported to, but doesn't write the data. This does not happen with regular MonetDB.
Our team is notified of this issue, and we're looking into it. Thanks for the heads up!
PS: Regarding your doubt about MonetDB/e vs MonetDBLite: our team no long develops and maintains MonetDBLite. Both are embedded databases that use MonetDB as the core engine, but MonetDBLite is deprecated. After having learnt some do's and don'ts with MonetDBLite, our team is developing our next generation of embedded databases.
So for your embedded database needs, you should follow what's coming out of our MonetDB/e projects.
I've created a test for it at: https://github.com/MonetDBSolutions/monetdbe-examples/blob/CI/C/copy_into.c
Also filed a bug report over on GitHub: https://github.com/MonetDB/MonetDB/issues/7058
We're currently looking into this issue.
To track changes in OSX filesystem while an installer runs I'm trying to use the fs_usage.
Can somebody guide me with a simple example on how to interpret the result. There a lot of terms I don't understand when I examine it.
fs_usage's output tends to be full of irrelevant chatter, and hard to interpret. I'd recommend using fseventer, which just shows changed files without all the nonsense. If you're an Apple developer, you can also use PackageMaker's snapshot package feature (which records everything that happens, and offers to make an installer package that does the same things).
I recently moved my whole local web development area over to using MacPorts stuff, rather than using MAMP on my Mac. I've been getting into Python/Django and didn't really need MAMP any more.
Thing is, I have uninstalled MAMP from the Applications folder, with the preferences file too, but how come when I run the 'locate MAMP' command in the Terminal it still shows all my /Applications/MAMP/ stuff as if it's all still there? And when I 'cd' into /Applications/MAMP/ it doesn't exist?
Something to do with locate being a kind of index searching system, hence things these old filepaths are cached? Please explain why, and how to sort it so they don't show anymore.
You've got the right idea: locate uses a database called 'locatedb'. It's normally updated by system cron jobs (not sure which on OS X); you can force an update with the updatedb command. See http://linux-sxs.org/utilities/updatedb.html among others.
Also, if you don't find files which you expect to, note this important caveat from the BUGS section of OSX' locate(1) man-page:
The locate database is typically built by user ''nobody'' and the
locate.updatedb(8) utility skips directories which are not readable
for user ''nobody'', group ''nobody'', or world. For example, if your
HOME directory is not world-readable, none of your files are in the database.
The other answers are correct about needing to update the locate database. I've got this alias to update my locate DB:
alias update_locate='sudo /usr/libexec/locate.updatedb'
I actually don't use locate all that much anymore now that I've found mdfind. It uses the spotlight file index which OSX is much better at keeping up to date compared to the locatedb. It also has quite a bit more power in what it can search from the command line.
Indeed the locate command searches through an index, that's why it's pretty fast.
The index is generated by the updatedb command, which is usually run as a nightly
or weekly job.
So to update it manually, just run updatedb.
According to the man page, its database is updated once a week:
NAME
locate.updatedb -- update locate database
SYNOPSIS
/usr/libexec/locate.updatedb
DESCRIPTION
The locate.updatedb utility updates the database used by locate(1). It is typically run once a week by
the /etc/periodic/weekly/310.locate script.
Take a look at the locate man page
http://unixhelp.ed.ac.uk/CGI/man-cgi?locate+1
You'll see that locate searches a database, not your actual filesystem.
You can update that database by using the updatedb command.
Also, since it's a database, unless you do update it regularly, locate wouln't find files that are in your filesystem that arn't in the database.