July 27, 2010 at 8:28 am
I have some SSIS projects that were created directly on the SS2k5 box that I can remote connect into the desktop on. All designer functions work fine and I created some Script Tasks and all works well.
Recently, we decided that we didn't want a bunch of people remoting into the server:w00t: so we decided to share the SSIS folder on the server to our ActiveDirectory group.
It seems to work fine except for a couple of glitches. Running the SSIS designer from my machine is an absolute dog with just 2gb of system memory plus the IS service being on another machine. I can live with that if it weren't for the other problem:
If working on the server, everything is fine. Otherwise, I work from my machine and whenever I work on a package, I double click on a Script Task and then click DESIGN and Nothing! Absolutely nothing. It doesn't even try to open the design window.
I thought it might be ownership, rights, etc. But, I created a new project by running on my machine and created it on the share, dropped a Script Task on it and nothing!
We are only allowed two connections on the server and we now have several SSIS designers so I am pretty much on the hotseat now and can't get off it!
Help.
July 28, 2010 at 9:06 am
I have done a remote connection to SSIS before and you're right it is slow, but never had the issue you described. Even thought you can open it, you might want to double check on the access rights.
July 28, 2010 at 12:42 pm
Can I ask a larger question?
Why are you designing the packages right on the server?
How do you handle version and code control? How do you prevent 2 people from trouncing each other's code?
CEWII
July 29, 2010 at 7:21 am
I know I set up a bad model I did not have complete control of the environment but, I am responsible for it. Go figure.
I am revamping it now that the powers that be know they screwed up.
It would be nice to find a white paper about organizing a multi-developer centralized environment (source pkgs in a central location) with the dev happening on the dev's desktop and eventually the deployment is in the msdb on the Sql Server being run by an Agent job.
Most of what I am reading is not in English but, assumes I know ALL terminology and have worked with everything they have. NOT.
Don't talk about a Deployment Manifest if I don't know exactly what it is and used for!
Sorry for the rant. I am frustrated because I am trying to right a wrong (our environment) and VS is not cooperating. And, I am trying to find a good deployment model that will work for US because one size does not fit all.
August 3, 2010 at 11:08 am
Agreed, one size does not fit all, however there are some fairly hard rules to follow.
1. Use a Source Control system, SVN, VSS, TFS, Vault, etc.
2. All code deployed is in Source Control. Sprocs, Tables, View, Functions, SQLCLR, DTS, SSIS, everything, this includes seed data.
3. Only one person edits an SSIS package at a time, EVER. No merges.
4. Source Control is the starting point of changes. Objects are NEVER changed on the server, they are checked out modified, checked in an then propogated.
5. Only check objects out to modify them, do not leave them checked out for longer than necessary. Nothing left checked out while you are on vacation.
6. (My Rule, mileage may vary) Don't check in code that doesn't work. This may be superceded by policy.
7. Everybody uses Source Control. Require all new projects to use it. Transition existing projects during next phase of project. No excuses.
8. Backup your Souce Control system..
My expectation for source control is that worst case scenario, I can rebuild a system from scratch with all the required structure and seed data.
This would be my starting point.
CEWII
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply