Hi,

Let's say 3 development teams (1 at customer's site, and 2 consultants) with no LAN or VPN to join them, only mail or ftp. Each team owns licences for SF and DDT, and can create deployment packages to apply on customer's SQL Servers (and of course on SQL Servers for tests at consultant's office)

When I receive customer's package, I can import it in a profile and deploy it from that profile. From another profile, I generate a package, and customer may deploy this package I'll send him. And of course, each deployment delete and  replace what was locally written

How could I merge the 2 packages into a single, in order to see all modifications in a single profile? from within DDT? with a merge replication in SQL Server? with a versionning product (Visual SourceSafe or another one)?

Thanks in advance for all advice.

The DDT isn't designed with that kind of versioning or "branch" system in place. If you want to have two autonomous teams that can't ovewrite each other's works, I'd recommend keeping two DDT profiles and deploying to two seperate databases. 

Is this for two seperate applications? Or do you have multiple teams working on the same application / database? If the former, than seperating them logically by team into seperate profiles and DBs would be the best bet. If the latter, than some parity will need to be kept to prevent overwriting (possibly seperate profiles, with apporoved changes being brought into the "production" profile?)

Dustin,

We have 3 teams, working on the same application/database:

• team1 is on the customer's site, and may modify structures, adding new tables and new columns to existing tables. They know all the industrial processes, and may "translate" in data structures new requirements asked by end-users
  Team1 is the origin of all DDT packages
• team2 receives DDT package from Team1, and may modify it, mainly by checking indexes, constraints, and foreing keys, and adding UDF and SP to database
  Team2 uses this DDT as a source for all BO: team2 writes BO library
• team3 is in charge of all presentation layer design, and receives DDT and BO library from team2. Team3 mays sometimes add few modifs on BO, if required for presentation layer.

To prevent overwriting, it seem that each team needs 3 DDT profiles. For instance, I am team2 (I am really team2 ).
I receive a package from team1, and imports it in profile "fromTeam1", then generate a package in the same profile, and import it in "My Profile".
Working in "My Profile", saving changes in my local Strataframe database, and finally I generate a pkg file to send to team1 and team3.

Do you think we need a database for each profile?

Well, based on that description, with all of you working on the same app just in different stages, I'd actually recommend getting VPNs set up to one central location, and managing it all on the same profile on the same server. That's what we do with remote teams, and it works well for us. That way there isn't any need to pass DDT profiles back and forth or do anything fancy to keep everything in line.

You just have to communicate with each other regarding what you are working on so you don't step on toes, but doing the above will keep you from losing work in the shuffle.

Dustin,

VPN is not an option here, alas!

Customer's requirement is that only domain members are allowed to remote connection, with only application rights on production SQL Server, and no rights on development servers...

That's why I imagined this 3 profiles schema, to manage incoming and outcoming packages. Is there another way?