I want to redeploy a package with sqlplus like that:
echo exit| sqlplus user/passwd#db #package.sql
I wonder if it would be possible to diff #package.sql with the existing package in db(if exists at all).
I'm using power shell for that.
Many thanks in advance!
I don't know whether you can do it using Power Shell. I'd
install Notepad++
then install its "Compare" plugin
use SQL Developer to easily access current package specification/body
copy/paste it into Notepad++
load package.sql into another Notepad++'s tab
compare both tabs
you'd see which lines are equal, which exist in one tab and not in another (and vice versa) - everything
If you want to do it "automatically" while running package.sql ... then
I have no idea how to do it,
might cost more than what I suggested ("cost" because you'd have to develop a program which would do that, and that takes time and effort), unless there's already some tool which lets you do it (but I don't know anything about it)
Related
I have exported my oracle apex application to take its back up.
It has multiple application files, page files, ui files etc. My apex version is 20.1 and i am using apex.oracle.com.
If i need to import this same application again, do i have to import all the individual pages one by one like they have been exported or is there a way to import them all at once?
I tried importing the zip file but its not working.
Please suggest a workaround to upload all files at once as there are around 40 page files apart from application files, user interface files, etc.
As far as I can tell, that won't work on apex.oracle.com.
I was thinking of Apex SQL Workshop, running multiple scripts at once (sequentially). Why? Because those export files are .SQL files so you can run each of them as a script. However, there's no such option.
If you load it into SQL Commands, it won't work because of invalid/unrecognized SQL*Plus commands such as whenever sqlerror exit sql.sqlcode rollback.
If it weren't for apex.oracle.com but your "local" Oracle database, the one you have access to and can use SQL*Plus, you could write a script that calls other scripts, but - as that's not your case, no use of it.
Therefore, I think that you'll have to import each of those files manually, one by one.
Each of the export files is a separate script containing a number of pl/sql blocks. You could try to contatenate them together into a single script, upload and run that. However there is a size limit to scripts so you'll probably have to use more than one.
Is there a particular reason you chose to export as zip?
You could just do a normal export, which will give you a single file with your application and most everything it needs all in one place and very easy to import when needed.
If supporting objects are a concern, create install scripts that build your tables, triggers, etc. and make sure to choose "Yes" or "Yes, and install automatically" in the "Export Supporting Object Definitions" drop down.
You can still download the zip too and stuff that into version control if that is needed, but for ease of restoring an application, the "normal" single file way is far easier to manage.
I'm looking of a DTSX file that I didn't make, trying to get an overview of how it works. But I've noticed that every time I open up an Execute SQL Task or File System Task it checks out the dtsx from TFS. I haven't changed anything, so why does it always check out the file?
Because the dtsx file is overly burdensome and mixes UI and data/programming elements in the same backing file? winces
Without seeing the specific file, what I had noticed back when I used version control systems that subscribed to the checkout/modify/checkin pattern is that things such as package configuration, expressions, etc may get re-evaluated as you open tasks which I assume the TFS modify daemon in VS detects the file could get dirty and so checks it out to help you.
You'll also notice that if you run the package, sometimes it gets checked out and marked as modified. Which is totally fun as you get to play: what was I doing before I left my desk? Did I actually make a change or was I just looking?
Not helping matters is that the save action from visual studio always triggers two changes: version build (which is a monotonically increasing number) and the corresponding version guid.
Not an answer, but I can commiserate with your experience. The answer likely lies in the engineering minds in Redmond and was never publicly documented.
I've run into the problem described in this question, where an old package was Obsoleted, and its %preun script is run with $1 = 0, resulting in undesirable behavior. I know this could be worked around by using -e + -i, as suggested in that answer, or the --nopreun flag, but it's difficult to get that information out to users who are accustomed to simply using -U.
I can't modify the existing %preun scripts in the wild. I don't see any way to run additional code from the new package after the old one's preun. I can't find any way to have my new package programmatically prevent the old %preun script from executing.
Is there any safe way to reach into the RPM database and remove a scriptlet for an existing package?
Jeff Johnson is absolutely correct that it should not be done. However it certainly can be done.
I have done this in an RPM at work, for distribution, but note, this was a contained semi-structured environment with no remote hands to all systems.
If you have remote hands access, take the "remove, install" path, and script that.
If you really feel you should be doing this, then these are the pointers. I'm not going to show you exactly how I did it because it was "work" and not mine to share. The concepts are mine :-)
First, back up the /var/lib/rpm/Packages file (cp /var/lib/rpm/Packages /var/tmp/Packages.bkp). Put it somehwere safe. Update your backup if any one else changes the system whilst you are working on your solution. MAke regular checks on the count of RPMs and test every which way from Sunday, after each change or step.
You will need to use the db_unload and db_load commands. For speed, you will need to use "s2p" to convert any shell sed patterns to perl. Then build a pipe which looks like this:
db_unload /var/tmp/Packages.bkp |perl -i -e "s2p converted string" |db_load /var/tmp/Packages.new
You can then attempt to test the Packages.new by copying ot over the original. Always run rpm --rebuilddb after manual changes. If you see any errors, restore the back up and rebuild the db again.
If you need to put it in an RPM, then convert it to Lua, and put it in the pretrans or posttrans scriptlet (%pretrans -p <lua>). The selection depends on the ordering you are trying to achieve. The Lua interpreter is built in to rpm, and so it will run OK during a new system install even if your RPM gets called somehow. I wrapped my "pipe" in a lua long string, and made it only execute if the system already exists. It does nothing otherwise. If you are thinking "that will never happen" then check out "Never say Never".
BTW you can completely stiff your RPM base and thus future administration of the system if you mess this up. If you do that, and have no backup or way out, it would be a hard way to learn that you are responsible for your own actions. Just saying that you have been warned!
No you cannot edit an rpmdb: the headers are protected
from change by a SHA1 or a digital signature.
Instead upgrade to a fixed version of the package using --nopreun
to prevent running the buggy script let.
I need somehow compare local version of pl sql package with the one that is stored in database. Are there any "easy" way to do it?
Currently I download package from database, save it in some file and perform diff using some diff tool. That is a bit cumbersome, so I would like to have such feature in ide (pl sql developer is preferable).
Typically developers use versioning software to check differences, maintain version history, and help coordinate team development of code. PL/SQL code should be no different. There's many ways to handle code releases, the following is just what I've seen done, not necessarily the "best" way.
In the Oracle environments I've seen, CVS or SVN is used. Most approaches involve checking out latest code from repository, editing (tagging/branching), and checking in. When code is tested (development instance) and release is ready, the DBAs either grab the release scripts from repository and apply, or one individual is tasked with handing over the correct release scripts to DBAs (more common from my experience). Note that the database here is typically a user acceptance instance that mirrors the production instance. If app testing passes, the code is promoted to production.
If you want to sync directly between the database and your IDE, the one option I've seen is Toad Team Coding. Toad is not free, and this option will require additional objects installed on the database (metadata/tracking tables, etc). A good overview is found here, and good setup article is found here.
Team coding is very cool, but I would only install on a development environment. How you promote the code from there through your system is up to you.
It's fairly easy to automate the procedure you described with a sqlplus command file. Select from all_source, spool it to a file. Invoke the diff command as "host diff ..." or "!diff ..." within the command file. The -b and -B options to diff will ignore whitespace and blank lines respectively.
Does anyone know where I would begin to write an automation script to install a CMS to my wwwroot folder and create the database for it? For this round it would be for DNN on in a windows environment.
I am looking for methods to speed up our development process in the office.
Many thanks!
First write a (textual) script of what you need to do.
Then convert these steps to automated steps.
The exact steps depend on the database and webserver you are using and on how you want everything to be configured, so get these steps clear before you start scripting.
Queries you need to execute can be put in separate files (usually with .sql extension). Most databases allow running those files from the command line.
Most other commands, like creating folders and such can be run from the command line as well. If you can run it in the command window, you can put it in a batch file as well to run everything at once, so you can translate all possible steps to a line (or group of lines) in a .bat script.
Identify the prerequisites, and generally they windows patches, db/sql server etc.
Determine how to install all the prerequisites from the command line.
Create your database manually and then script it out using something like sql server management studio or a third party tool such as the RedGate Sql Tool Belt.
Read up on how to install the CMS from the command line
Automate the installation of the above using a script language, such batch, Powershell, VB script etc.
Once you've got to step 5 you can ask more specific questions on particular aspects of this.