I'm getting a 1026 message ID error when I try to create a package. It indicates there is "No row at position zero". Screen shot attached.

Hey Greg, have you changed the structure of a table that you already had in the Deployment Data node?

I'm just deploying permissions and roles (and associated links).



So, if SF made changes then yes. I haven't.



I about to do a meeting, then finish a bug fix...so I'll get back to this tomorrow am.



Thanks for the ideas!

Yes, if I'm not mistaken the Security tables had a new field or something, so if you had the Security tables already in Deployment Data, that could be it. As Trent said, deleting the packages and generating them back again should do it. This boy is learning a lot...

LOL...Yeah, Ivan is right, there were some structure changes in the last update of the security.  So that could be what is getting in the way, but generally you get a different error.  But that is definitely a possibility.

OK, I deleted the data packages and then used the wizard to recreate the packages. After doing a bit of massaging to get them the way I like 'em, the package deployed nicely.



Next....



When deploying it, I get errors. When deploying to an existing db, I first get an error that it can't delete the file group...fortunately. (my history is completely clear and I'm using the $DbName$ token in the file group name). This is the case even if the name if the same as the db name in the DDT.



Then I get errors related to various items (PK, FK, views)...I'd post the log, but I can't find it



I tried to deploy it to a new db (using a new name), but it also errored out.



Probably the best would be to figure out were the log file is, then you could see the issues. Sooooooooo, were is that rascal?

Hmmm...you might let me take a look at your package and try it on my side so I can see it live and in color

Here is the package. I haven't had a chance to check it out yet, but I'm pretty sure the issue with it attempting to delete the data file is because I have a mismatch between the actual file name and the template assigned to the file group. However, as mentioned, I still get errors when attempting to load this to a new db.



I also figured out were the log files are...in the same folder as the package file...doh! I've attached the log file from when I was creating a brand new database.

I wil take a look at it.  From looking at the log file it looks as though the security tables are not up to date....but I will run it and see if I can see what is going on.

Thanks Trent.



Have a good weekend!

You too,amigo

Greg,

Did you notice that the SFSAuditDataActions and SFSAutodDataFields are in your package twice?  Just smoke one of them and see if the issue persists.  I will check to see if I need to make an import change to prevent this from happening again in the future, but this is probably the crux of your issue.

That helped, but still issues. It is barfing on the a couple of the SF security views, with this error:





I'm attaching the package and the log file.

Also, I'm also having problems managing my filegroups. I just have one (PRIMARY), but in some cases, the file was not originally placed in the standard SQL server data folder, but in another folder. I just noticed that I now have two data files (plus a log file): my original and an updated one added by the DDT. So, two questions:



1. Is there any way to set a folder for the file(s)?

2. How do I get rid of the extra data (.mdf) file?



I sometimes wish learning all this stuff wasn't so painful



Thanks!

Ahhh...priorities.  You need to set the view priorities since one relies on the other.  This is a relatively new feature of the DDT.  It will need to look like this:

I went ahead and made your profile work, so if you do this you should be in good shape.

We are adding a new feature...literally as we speak here, that allows you to have pre and post scripts that execute.  You would have to write a pre-script that sets the folder for you...which honestly I recommend against.  This is a setting on the SQL Server side of things and when you start moving the MDF file locations...well...it becomes a full time job and your responsibility instead of SQL Servers.  But if you have this need you will be able to set the folder location via a pre-execution script in the next update.

If it is not in use, then just "smoke it"  but if it IS in use, then you may have to detach it first.  Again, this would need to be done via a script...or manually through the Management Studio.