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.

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.

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

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

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?

The initial security project is from the samples that we distribute.  But it looks as simple as your server structures not being up to date.  All of the symptoms that you have described I have seen many times before...and everytime it ends up being the StrataFrame structures not beuing up to date (or people not connecting to a StrataFrame database...which generally produces other errors as well).  Please re-deploy the most recent version of the StrataFrame structures through the install to your server database again and let's see if they get updated.  Past that you are welcome to post the database in question here and we can attach it and run it on this side to see if we produce the same results...but I am very confident that your StrataFrame database structures are just not up to date.

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?

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.

Run?

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

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