I am hoping someone can explain the design intention, that I might be
better equipped to deal with this.

We are cooperating with another company, far away, to develop DTS
packages over long term. We do not (yet) have a way to network with
them, so we hoped to save to Structure Storage Files, and zip them up,
and send along that way. I am making a tool to automate moving stuff
back and forth, and keeping updates in VSS. I immediately having
problems with the first batch of updated packages. I found they sent
us a modified package. But for some reason the PackageID has changed
(and the name has not). So when I go to save it, in my server, it
won't do it.

I can replicate this behaviour (outside of my tool) with Enterprise
Manager.

I really don't understand why if the NAME IS THE SAME that SQL doesn't
simply make this SAVE the latest version. Why even bother to have a
Package GUID, given how it behaves? There must be some wisdom or
philosophy for engineering the possibility of this conflict into the
system, which I am not understanding. It could very well be that if I
understood I could make something that flows and works better. Who
changed the PackageID? Was it changed when doing a SaveAs to SSF at
the other end?

It seems DTS is trying to enforce that if the NAME is the same, then
the package itself is probably different, and MAY NOT simply be a new
version. Where to me, the later seems more likely to be the case.
Especially considering that there is version management in DTS makes
it even more puzzling to me.

BTW.... I thought about taking and altering the PackageID of the
just-loaded-from-SSF Package2 object, to be that of the package
ALREADY in my server by the same name. But for a Package2 object,
docs tell me the PackageID is read only.

Any insight or perspective you can share would be GREATLY appreciated.

TIA - Best regards, Lee Gillie - Spokane, WA

By using a package Guid you can ensure than it multiple developers create a
package of the same name that when they are deployed to the same location
that you will detect the clash. Not sure if this was MS's major goal, but
with distributed development it makes sense. The Id will change whenever you
do a Save As, since this then becomes a new package.

You can either write your load process to handle duplicate names, and first
delete the duplicate, or look at alternative transfer methods that do not
use Save As. I think the first option would be much better as when
developing a useful methodology is to generate packages in code, which of
course re-creates the package and hence changes the Id.

--
Darren Green
http://www.sqldts.com



"Lee Gillie" <ANTISPAMIFICATION_lee (AT) odp (DOT) com> wrote

Thank you, Darren, for taking time to reply, and your insight.

I did think long and hard about deleting conflicting packages locally,
before attempting to save an imported version, which was modified
remotely. In doing so, I loose prior versions of the package. A goal
for me was to retain them. The idea being that with both old and new
version in place my tool can do a "differences", and report what
changes were made while the package was checked out to the remote. I
use VSS ONLY for a textual rendering of the package, which my tool
creates, and this is solely for the purpose of using with a
differences tool, and to allow developers at diverse locations to
annotate their work. The idea is the old version is both available in
SQL packages, and also, the VSS snapshot of the work, and my tool can
"execute" the old version or a current version.

I have not explored repository... perhaps an answer there, but I think
the concept has probably been consistently implemented.

I dislike having the choices engineered out of the system, for me, but
that's what I have to work with. I wish I could have the choice
telling DTS I expect this to be unique, or that I expect it to
pre-exist, and if it does, then I have a new version, not a different
package. Changing the storage medium alone, should not implicitly
imply a totally new package. It seems like very short sighted design
work. I think I am starting to rant.

Thanks again, Darren. BTW, also thanks for the great SQLDTS website
you maintain. It is a huge service. I studied the articles there long
and hard (weeks ago) before beginning this project, which is a new
venture for me into DTS technology. Really GREAT stuff!

Best regards, Lee Gillie - Spokane, WA


"Darren Green" <darren.green (AT) reply-to-newsgroup-sqldts (DOT) com> wrote in
message news:eXJJOeo1DHA.2396 (AT) TK2MSFTNGP09 (DOT) phx.gbl...

Lee,

I don't quite understand how you will use Visual Source Safe to do a
differences report of a structured storage file. To do this you would need a
code representation of the package as you get when using the Save As VB
option in the designer. You could do a comparison through the object model
through.

If you find the storage options supplied too restrictive then there is no
reason why you could not use your own. At the end of the day the Load and
Save method s are just wrappers around the COM structured storage format,
with the final destination being a file or a table. You could wrap the
existing methods and use a temp file or a temp row in sysdtspackages, or
even write you own entirely.

If you are controlling the access to the packages yourself then you could
just ignore the supplied name and create your own, perhaps appending your
version number onto the end of each package, e.g. PkgAName_1_1,
PkgBName_1_1. You can then treat the name and version as two parts, or a
single unque id.Since the name is now unique, then you should no longer have
issues with what DTS thinks should be unique or not.

--
Darren Green
http://www.sqldts.com



"Lee Gillie" <ANTISPAMIFICATION_lee (AT) odp (DOT) com> wrote

"Darren Green" <darren.green (AT) reply-to-newsgroup-sqldts (DOT) com> wrote in
message news:ekaDx7s1DHA.1676 (AT) TK2MSFTNGP12 (DOT) phx.gbl...
I use VSS only for a TEXTUAL RENDERING of the package, and not SSF.

I had HOPED to SaveAs VB to get my textual rendering. But now I am
working on something that provides an organized report of the content
of all of the objects, and properties of objects, which I can traverse
in the Package2.

For example, each time someone wants to work on a package, I would use
VSS to arbitrate check out of a "textual rendering" of the package.
The textual rendering is discarded, but the lock has been taken, and
the user has permission now to SAVE the package. When they are done
they use my tool to check it back in. It is arbitrated they have it
checked out. Again a "textual rendering" made and checked into VSS.
VSS does not actually store the SSF, or VB, etc., it merely holds a
report of what the package looked like. Now I come along, and try and
figure out what that last change FRED made, that is causing trouble
somewhere, and I can use the DIFFERENCES capability in VSS to show me
the variation in the two textual renderings. I can quickly see that
FRED tweaked this property of this object, or this line of Active
Script code, or... what have you. I prefer to work on large projects
in compiled code, and so this gives me back something I am used to in
VB or C++, but which DTS itself does not provide. And that is VSS
features, PROVIDED everyone uses this tool to arbitrate work.

Yes, I think what I should have done, was to NOT use SQL SERVER for
storage of packages, and instead, solely use on-disk SSF. I think
then, folks could make changes. Save them back to SSF, and HOPEFULLY
the packageID would not have been tweaked in the process. Had I
understood this to start with, I would have made this approach from
the get go. I plan to research feasibility of this next.

True !

As with anything new, the things we learn by such trials, we tend to
remember the most. Many thanks again, Darren. Best regards, Lee