When I click on the ViewSecurityKey for a Form I get this error...

Any ideas why?

Thanks

In the case you haven't done anything new after moving to the server, you could try detaching the StrataFrame database from the old place, also detaching the StrataFrame database from the server, then copying from the old place onto the server, and ataching it back again.

Well, in trying to get this to work with the dB on the server, I toasted my local copy. Other ideas?

Run?

Well, with the info we have so far I can't think of anything else, but the other guys might do it.

Let's just back up for a minute and get a clean SF database installed period...and then we can worry about data.  Backup and remove the StrataFrame database on your server altogether (key word is backup).  Next, re-run the SF install and let the database be installed.  This should give you a clean install.  Let's do this first to see if we can get past your error.  Then we will go from there.

I've been playing around with this, and it appears that there is something stopping me from opening the Solution Preferences when my Database connection is pointing to my server connection.



I've been able to get it to open after removing all of StrataFrame, and re-installing the dB locally. The questionable thing though, is that even after the install and not setting up security, there is an entry (my initial Security listing when I first installed) in the list of Security preferences in the Solution Preferences. Something isn't getting cleaned up or allowing my new dB connection to be used.



Any further ideas?

Please ignore this last (duplicate) posting. I didn't notice that the topic ran onto another page, and resent it. Sorry.

That just confirms what I have been saying...I really don't know how else to put this so let me just give you a check list and let's start over.  Let's get back to groudn zero because this really shouldn't be so hard to fix:

1. Remove all of your current connection string information by deleting the AppKeys.dat and Connections.dat files located in the C:\ProgramData\MicroFour\ConnectionData folder (for Vista) this will appear under the Documents and Settings if you are still on XP
2. Close down VS
3. Mount the database to which you want to update
4. Deploy the SF structures to that database through the install.  BE SURE TO PROVIDE A SQL USER THAT HAS FULL PERMISSIONS!
5. Now, go back into VS and you will be prompted for the database connection to the SF database
6. Set the connection

At this point you should be good to go...it is really that simple...I promise

I should have noticed this before and mentioned it, but in some of the other topics, there was mention that there shouldn't be issues. I'll try what you mentioned Trent, but I'd like to throw this into the equation as well.



I do have a major difference in my databases; my local copy is MS SQL Server 2005, and my server is SQL Server 2000. For the tables between the 2 instances, the data type varchar(MAX) is used in place of text. In a regular Select statement this shouldn't matter. But through code, if you are typing your data retrieval, it can possibly have an affect.

No, the DDT takes all of this into account.  When deploying to SQL Server 2000 it uses Text instead of VarChar(MAX)...and as for the queries...they work.  We have many shops still running SQL Server 2000...so this isn't the case here.

2 things Trent. First, I tried what you stated and I'm still having the same issues; can't open the Solution Preferences and I can't set the ViewSecurityKey on a form.



Second, and this goes back to my last post. The error message I receive when I attempt to set the ViewSecurityKey for a form is explicitly stating that it is having a conversion issue when converting a text data type to an nvarchar.

Doug...I am very familiar with this code (I wrote it)....and I am also very confident as to what causes this error.  Instead of going back and forth, do as I mentioned in an earlier post...attach your strataframe.mdf file here, we will update it for you and then either tell you how to fix it on your side or send you the fixed mdf.  The only other cause could be assemblies that are not up to date (which in this case it would be the addins or extensibility assemblies).  Make sure that you have only a single instance of them in the GAC and the latest.  But give us your database first and we will prove that the database is not the problem.  Thanks.

As requested, here you go. Also attached is a screenshot of the GAC assembly.



I'm not trying to place any blame here. I feel I'm following the instructions to a tee. I'm just following the leads I pick on that I'd follow.



BTW, Cowboys over the Deadskins.

That'll always win you some points with me

Doug, you have to include the log file as well (ldf) in order for us to get this re-attached.  Thanks.

Take 2.