StrataFrame Forum / StrataFrame Database Deployment Toolkit / Issues / Event ID: 1026 / Latest Posts

RE: Event ID: 1026

Ben Chase — Mon, 04 Dec 2006 13:40:31 GMT

That it will...

RE: Event ID: 1026

Chris Crabtree — Mon, 04 Dec 2006 10:07:24 GMT

The root of this issue turned out to be some missing support for schemas in the deployment data packages. Trent figured it out on Saturday and updated the code for me, and I'm sure it will roll into the next release for everyone else out there using schemas.

RE: Event ID: 1026

Trent L. Taylor — Wed, 15 Nov 2006 09:54:40 GMT

[quote]I can't rename the db first and then create the data package, because the source data connection will try to read from the new database name, which of course does not exist on SQL Server (yet).[/quote]

If you are referring to the Data Deployment Packages, something has to exist before it can pull in data for deployment. If this is not what you mean, then I guess I don't fully understand your problem.

[quote]I also can't just rename the database on the SQL Server side and have DDT recreate it, because it complains about the default database filenames already being in use, etc.[/quote]

This is because when you change the database name, the file group name will remain the same. Change the primary file group data file name so you do not have a conflict of MDF files on your server.

[quote]Is there a high-level bullet-point walkthrough of redeploying an existing db onto the same server under a different name? Or is it simply not worth the effort, and I should just deploy to a new server?[/quote]

Not yet. This is something that will more than likely be added to the framework fairly soon as there are a number of requests of being able to deploy the same structure under different names. We too have this need.

RE: Event ID: 1026

Chris Crabtree — Wed, 15 Nov 2006 09:46:22 GMT

I can successfully package the thing now, but as I recreate the data deployment package, it struck me that I can't seem to do what I want.

I can't rename the db first and then create the data package, because the source data connection will try to read from the new database name, which of course does not exist on SQL Server (yet).

I also can't just rename the database on the SQL Server side and have DDT recreate it, because it complains about the default database filenames already being in use, etc.

Is there a high-level bullet-point walkthrough of redeploying an existing db onto the same server under a different name? Or is it simply not worth the effort, and I should just deploy to a new server?

Not such a big deal for me since I am in a server-rich environment :-), but just curious at this point.

Thanks!

RE: Event ID: 1026

Trent L. Taylor — Wed, 15 Nov 2006 09:29:39 GMT

Try that and see if this is your problem. If not, could you just send me your package file so I can see where it is failing?

RE: Event ID: 1026

Chris Crabtree — Wed, 15 Nov 2006 09:28:10 GMT

Yes, the one I created shortly before the database rename...should I kill it and recreate the data package with the matching name?

RE: Event ID: 1026

Trent L. Taylor — Wed, 15 Nov 2006 09:21:04 GMT

Do you have any Deployment Data packages?

RE: Event ID: 1026

Chris Crabtree — Wed, 15 Nov 2006 09:01:55 GMT

Forgot to mention that I am using a non-default schema (not 'dbo') for all of the tables in the database, if that makes any difference. Thanks!

Event ID: 1026

Chris Crabtree — Wed, 15 Nov 2006 08:54:18 GMT

I dusted off my project this morning needing to deploy it to a production server. This is my first time using the data deployment feature, so I thought I'd better test it first.

So I renamed the database within DDT, planning to deploy to my test server, after which I would rename it back for the production deployment.

Rename went fine, but now I get:

An error occurred while attempting to create installation package. See below for more details. Error Message Invalid object name 'BenefitLife'.

Now, 'BenefitLife' just happens to be the first table in my database, and I never touched it--as I said, I only changed the database name.

Obviously, I changed the name back to the original, removed the name history records, etc., and I am still getting this same error.

What should I look at next? Thanks!