Excellent glad to hear it.

That did it!  Thanks!

OK, the reason you're getting that exception is that the Northwind connection is the active connection.  The Database Connection option in the StrataFrame menu is not used for your application's connections.  The only connection that should be listed within the Database Connections is the StrataFrame connection.  Your application's connection string is configured through the SetDataSources() method of the AppMain.vb (or program.cs file).  So, the StrataFrame design-time components were trying to use the Northwind connection to find the StrataFrame tables (which is, of course, not going to work ).  So, delete that Northwind connection and configure it within the SetDataSource() and set the active StrataFrame Database Connection as the correct one within the Database Connections dialog.  The BOMapper will come back to life.

Since I was getting nowhere with the 1.4.1 release, I deinstalled everything again, dropped the StrataFrame databases, and verified that everything was deleted.  I then installed the 1.4.0 release, verified the StrataFrame databases were created, verified the StrataFrame database connection exists and points to the correct database.  I then created a new StrataFrame Windows application project in VS2005.  Then I went to the Business Object Mapper and clicked on it.  I am still getting the same error as before.  The StrataFrame database does have a table named DTEprojects, and that table is empty.  

I do NOT have the Database Deployment ToolKit.  Since this an optional product, could this problem be a dependency issue?  When I was playing with the trial license, I did have this tool loaded and I didn't have any problems with Business Object Mapper.

I have 2 database connections.  One for StrataFrame and one for Northwind (my testing DB).  The Northwind connection was the only one with the green checkmark on it.  I deleted and recreated my connection for Northwind and edited the StrataFrame connection.  I changed both servers from Localhost to the server name (shouldn't make any difference, but tried it anyway) and saved the connections.  The connection info is correct, the server is up and running, and is available. 

After doing the above, I'm still getting the original exception.

Joe,

Check the StrataFrame database connection within Visual Studio and make sure it is configured propertly.  Open the Database Connection option from the StrataFrame menu within Visual Studio and edit the one that has a checkmark on it.  It should be pointed to the location where you have your StrataFrame database installed.

FYI, the StrataFrame database does have a table named DTEprojects.

I'm having the same problem as CT had initially (Invalid object name 'DTEprojects'.).  I originally had the trial edition loaded, deinstalled it, and then loaded the licensed 1.4.1 prerelease.  That is when I ran into this problem.  So, I deinstalled everything, dropped the three StrataFrame databases, deleted all StrataFrame directories, and verified that the GAC no longer had any StrataFrame assemblies (except for the license assembly which I could not delete).  I then reinstalled StrataFrame and verified that the 3 databases were recreated.  I am still getting the same thrown exception.

So, based on the info in the previous posts, there must be a problem in one of the databases.  Can you provide the info I need to fix the database?

Thanks!

CT,

I have recompiled the assemblies with the latest changes and attached them to this post.  To get your GAC and assemblies up to date, do the following:

1. Close down all Visual Studio Instances
2. Download the attachment
3. Extract all of the files (XML and DLL) to the "c:\program files\common files\microfour\strataframe" folder overwriting the existing files.
4. Open two Explorer Windows.  Navigate one to the "c:\program files\common files\microfour\strataframe" folder and the other to the "C:\Windows\Assembly" folder.
5. From the Common Files folder (where you extracted the new files) select the MicroFour StrataFrame...: AddIns.dll, Base.dll, Business.dll, DBEngine.dll, Extensibility.dll, Inherited UI.dll, UI.DLL
6. Drag the selected files into the "c:\windows\assembly" folder (GAC)
7. You assemblies will now be on the latest version.
8. Go back into Visual Studio and see if the error persists

If the error still occurs at this point, I know for a fact the the structure on the SQL Server does not match the business objects in the assemblies and we will need to get your data structures up to date.

Let me know if this gets you going.

CT,

It is best not to add the SF source projects to another solution...especially web because this can cause you some frustrations...as you have seen.  Web solutions behave differently than Win solutions...this is just .NET.  To put the SF solution into a state where it can be debugged through any format, do the following:

1. Open the SF source solution
2. Build the solution in debug mode and make sure that all 4 assemblies built and were added to the GAC (you can tell this by looking in the Output window.
3. Close down all Visual Studio instances
4. Open up you web solution
5. Remove the SF projects from the solution
6. Remove the SF references and add them back in from the GAC (.NET page tab).  This will make sure they are no longer referencing the SF libs through the project
7. Build your web solution in debug mode.
8. Now when you step into an SF command, it will take you directly to the source

The errors you are getting is due to a reference in the GAC and a referenced project through the web solution.  There is a conflict and this is why you never want to bring the SF libraries into a solution.  You really don't need to when you have them in debug mode because when you step into an SF command it will automatically open the proper source file for debugging.

If you get stuck let me know and I will help you out.  Once you figure this out once it is all downhill after that .