as far as I understand, powershell has one profile per user. I would like to prepare multiple environments for different "hats" I could put on my head. Like start my "database worker shell" which provides a set of shortcuts for working with special databases. Later I would start an environment which might be my "data processing shell" that provides other shortcuts.
What's the best way to manage that?
cheers,
Achim
I believe there are quite a number of ways and “the best one” depends on many not explained factors. One not best but kind of straightforward way is the following.
Profiles are just scripts automatically dot-sourced in the global scope on start-up. In some sense we can call any script that is dot-sourced in the global scope later “a dynamic profile”. We can have several scripts that install global variables, functions, aliases and etc. with the same names but different values. In other words, we can have several scripts that install different “environments”. At any moment we take one and do:
. Set-Environment<SomeName>.ps1
and continue work with new environment SomeName. More or less, I use the approach like this in practice (exactly when working with databases, BTW).
Related
Just a bit of background on where my question is coming from: my company has multiple databases across the globe that uses the same schema and once of my department's responsibility is to monitor and make sure all these DBs are in sync from a schema SQL change perspective.
Now, my question is if anyone knows of any Software/tool that has a a Frontend UI which is able to do the following (the lower number the more important to have):
Able to track what SQL code change was applied on which database and when. Basically, if we write a SQL query that changed the structure of a table and we need it applied to 80% or 100% percent of the DBs, either via manual input or some automatic check the tool will tell me that yes, this was indeed applied.
Code distribution tool: we give it the query or a file that contains the code and it's able to push to the Databases it needs to (and create the audit log for that)
Code/object repository: keeps track of what was custom developed and pushed to the databases
I know SSIS might be able to do some of these things, but we need a tool that also has a simple frontend interface that can be accessed by non-IT personnel. (*clarification: we are not planning on giving non-DBA people access to change things, just to the audit aspect of said tool)
I've tried searching the internet, but i have a feeling i'm not using the right vocabulary to get the results i'm looking for.
Hence i wanted to see if the community was aware of any such tool or something similar?
Try searching for one of these two types of systems:
Release/Build/Deployment Automation Complex programs like Serena that have modules for pushing, tracking, and auditing any kind of software, anywhere. These will include all the GUI bells and whistles. But you'll have to deal with extra databases, configuration, agents, workflows, consultants(?), etc. These programs are geared more towards developers.
Remote Execution/Configuration Management Simpler programs like Salt, Fabric, and Ansible that let you run operating system commands anywhere. They don't offer as many features, and you have to do more of the work yourself, but in some ways that's liberating. If you know exactly what commands you want to run you don't need some other program holding your hand. These programs are geared more towards administrators.
From a database administrator's point of view, the main problem with those types of programs is that none of them are relational. Yes they can connect to a database and run a script, but none of them really speak SQL. Their native languages are Java, XML, SSH, etc. There's nothing wrong with those technologies, but if you only care about databases you don't want to deal with all that complexity.
If you're not happy with either of those types of programs I recommend you look at my open source program Method5. It is a remote execution program built as an extension to Oracle SQL. It works entirely inside an Oracle database, so you can install it yourself and won't need any additional websites, agents, configuration files, GUIs, etc.
Based on your comment about getting bogged down by links, and my answer to your question about half a year ago, I think this is the kind of program you were gradually heading towards creating. It took my team a couple thousand hours of developing and testing to get it right so you were probably wise to give up on making your own.
To specifically answer your requirements:
Tracking Changes are stored in an audit trail. But more importantly it has the ability and a pre-built script to compare an unlimited number of schemas, all in one view. At the end of the day what you really want to know is "are my schemas the same", not necessarily "did the same thing get run everywhere?".
Code Distribution If you just have SQL or PL/SQL, deploying it through Method5 is as easy as it can possibly get. Just specify what you want to run, and where you want to run it, like this: select * from table(m5('create index ...', 'dev, qa, prodDB1, prodDB2')); The program does not (yet) run SQL*Plus scripts. But when you have the ability to run SQL and PL/SQL so easily there's little need for SQL*Plus.
Code Repository All executions are stored in a simple table, M5_AUDIT. It contains the code, who ran it, where they ran it, and how they ran it. It wasn't designed to be a repository like SVN but it's good enough for simple auditing and tracking code.
Method5 does not contain a GUI but in some ways I consider that to be a feature. Since everything is done relationally, everything is in a simple table. You can use any of your existing GUIs - Toad, PL/SQL Developer, Excel, Apex, etc. It's a robust back-end solution that will hopefully make a good foundation for easily building a simple front end.
This question pertains to the i5/OS (mainframe, as400, etc.) and its programs that are written in CL. How does one access the parameters within a given .PGM extension file (RPGLE) outside the application itself and without admin privs?
I have tried all available and related functions within the as400 app itself. None of them work. At least not with my user privs.
Overall, this mainframe app utilizes hundreds of libraries within libraries. Add thousands of files to that and you have a daunting task of accessing relevant data outside of the limited menu functions / programs(.PGM file extensions) for which you are granted access.
Frankly, the programs just suck. I really like using a SSH connection and qshell to execute SQL statements to bring up tables within the libraries. I can customize what tables are accessed and how the information is fetched.
This particular program acts as a basic query that accesses data from several tables, presents it in a new table that and allows for realtime filtering based on a limited amount of criteria.
I have tried the CAT command as below:
$ cat someprogam (and several variations with and without extensions, I forget)
But these just give me error codes
I have also tried executing SQL statements at the db2 prompt, but I get SQL STATE return codes (this isn't a .FILE extension so yes it makes sense that it wouldn't work the same way as selecting tables would).
I'd prefer accessing the data within qshell. Perhaps I am doing something wrong? Any help is greatly appreciated. Thank you
Qshell is an alternative operating environment to what I'll call native for lack of a better name. Qshell is similar to AIX but not 100% identical. Qshell does not map the output of native programs to stdout, so you can't access the output of a native program via pipes.
If a native program writes to a display, the only reasonable way to redirect that output is to screen scrape it, which can be done by writing your own tn5250 emulator, intercepting the screen output and putting it where you want it to go, including stdout. This is not particularly simple if you're not comfortable with the 5250 communications protocol.
You have two vaguely practical options. 1) Write many SQL stored procedures which, coupled together, replicate the business logic embedded within the programs you want to execute. 2) Ask the midrange developers to refactor out the business logic into a service program (they should understand this) and write a stored procedure for you to use. This way, both the midrange programs and external consumers (you) can reuse the same business logic. And when (not if) that logic changes, it'll change in one place, and all consumers will see the new rules.
We're currently using VincentVega (now rolled into Tarantino) for our database CI. We're using CruiseControl.Net for our web app (C# using TFS).
VincentVega has worked out relatively well since it's very explicity and handles the two scenarios of create and update (while preserving existing data) equally well. I'm looking into upgrading to Tarantino, but I'd like to know if anyone might suggest some alternatives I should look into? Tools like SQL Compare that "automagically" produce delta scripts are out of the question, unfortunately, since our database is highly normalized with over 500 tables.
Thanks
Eric Tarasoff
There is also another project which may be worth looking at by Rob Reynolds; RoundHousE
http://code.google.com/p/roundhouse/
The wiki is at https://github.com/chucknorris/roundhouse/wiki
There's a similar tool by Paul Stovell and friends called DbUp.
One notable difference between Tarantino and DbUp is that while Tarantino is typically called from a build script (like Nant or msbuild), DbUp has .NET classes you use within your application. This potentially allows for better fallback handling in case a script doesn't go as planned.
http://code.google.com/p/dbup/
Here's the original announcement of DbUp from Paul Stovell's blog:
http://www.paulstovell.com/dbup
I think it might be of interest to post another answer since Redgate now has a new offering, ReadyRoll, that satisfies your key concerns.
"it [SQL Compare] just doesn't put together a synch script correctly"
Yes, diffing tools can sometimes get the script wrong. Often it's not that the script doesn't work, but it doesn't apply the change in the desired way. ReadyRoll's best-of-both-worlds approach uses SQL Compare under the hood to create each migration script, but crucially it allows the developer to customize the script afterwards.
"RoundHousE and tools like it already operate in a model similar to what we're doing now"
ReadyRoll's approach is, like RoundHousE, migrations-based, managing the upgrade process by running a series of consecutive scripts. This tool was built in recognition that many development teams prefer working this way.
"One last reason for choosing RoundHousE: Chuck Norris"
I will have to concede defeat on this point...
What would be the best approach for versioning my whole database ?
Creating a file for each database object (table,view,procedsure..) or rather having one file for all DDL scripts and any new change will be put in a separate file ?
What about handling changes made in a Database manager tool ?
I'd like to have a generic solutions for any kind of RDBMS.
Are there any other options ?
I'm a huge VCS fan in general and a big Mercurial booster, but I really think you're going down the wrong path.
VCSs aren't just about iterative changes, the "what", they're also about answering the "who", "when", and "why". For a database those answers are a lot less interesting or hard to provide to the VCS. If you're doing nightly exports and commits the "who" will always be "cron" and the "why" will always be "midnight".
The other thing modern VCSs do really well is helping you merge changes from multiple branches. That's less applicable in the database world. Very seldom do you say "I want this table structure, but this data", and if you do the text/diff merge isn't going to help you much.
The thing that does do "what" and "when" very well is an incremental backup system, and that's probably the better fit.
At work we use Tivoli and at home I use rdiff-backup and duplicity, but there are plenty of great options.
I guess my general rule of thumb is "if it was typed by hand by a human then it does into source control, and if it was generated/exported then it goes in the incremental backups"
Certainly you can make this work, but I don't think it will buy you much over the more traditional backup solutions.
Have a look at this post
If you need generic solution - put everything in the scripts (simple text files) and put under Version Control system (can be used any of VCS).
Grouping similar database objects into scripts will be depend on your requirement.
So you may for example:
Store table/indexes/ in one or several script
Each procedure store in individual script or combine small procedures into one script.
However need to remember one important thing with this approach: don't forget change scripts if you changed table/view/procedure directly in databases and don't create/recreate/compile you db objects in database after changing scripts.
SQL Source Control currently supports SVN and TFS, but Mercurial requests are increasing rapidly and we're hoping to have a story for this very soon.
We use UserVoice to measure demand so please vote accordingly if you're interesting in this: http://redgate.uservoice.com/forums/39019-sql-source-control
I had a (friendly but heated) argument with my lead developer the other day because our project has TSQL Scripts that I code directly into SQL files which I then run against the database. I find that when I do this, it's easy to work out the schema in advance without fiddly pointing and clicking and then there's no opportunity to forget to generate a script to put into source control as generating the script no longer becomes a chore you have to do after the fact, but is an implicit part of the process (and also leads to cleaner scripts without the extra crap that SQL Server Management Studio inserts into the scripts it generates).
My lead developer insists that having to manually script it out is a pain in the arse and that he absolutely refuses to write his scripts by hand when there are perfectly good tools to do it without coding. I've noticed that the copying of his changes into the actual scripts tends to get delayed a bit as a result though.
What are your thoughts on the pros and/or cons of doing it one way vs the other? Am I being too rigid/old-school in my sticking to hand coding schema scripts or is he being too reliant on third party tools and losing something in the process?
I always script stuff myself because the wizards sometimes don't script things in a way that I like it and will also give funky names to defaults
scripting things yourself is also good in case you get laid off and you have to go for an interview where they ask you to script DDL on the whiteboard
As I usually collaborate with a colleague during the schema design, I tend to design the schema using the GUI tools, as its easier to discuss it with a diagram of the tables in front of you. I then generate the scripts, being careful to select the exact options that I want to avoid having to make manual changes post-export.
I think a decision on the relative merits of the two approaches might take into account factors such as
the frequency of changes to the schema
the frequency with which changes need to be propagated to other schemas (test, user acceptance, production, clients * n, etc)
the degree to which the schema may vary across development branches
how well-known in advance your various changes can be scheduled
whether or not you can generate SQL "diff" scripts between schemas.
On balance, I tend to prefer to work with a script for each change (or "migration"). It lets me resequence change releases as priorities shift.
Just because you can create tables in a graphical tool doesn't necessarily mean you should.
I find its as quick to write a script as it is to use SQLMS. You still have to type names in SQLMS, and the time spent moving from keyboard and mouse could be used writing the proper script anyway.
The two of you are almost working with two sets of code. Consistency seems to be a key factor on these types of decisions. In your case, if you create a script, your boss uses the gui to add a field, how do you stay in sync? You can't use your script to rebuild the table without editing it (Chance for error.).
Maybe he should pull rank and force you to format your scripts the same way the GUI creates them - just kidding.
I think you should flip on it..........