Hi Larry.

After reading your post I thought that you should know that your statements about StrataFrame are not accurate and I wanted to clear this up for you. First, you mentioned that StrataFrame does not create teh CRUD settings, etc. for you. Actually StrataFrame has a tool called the Database Deployment toolkit that will create all of this for you. I understand that you use xCase, which is fine, but you can still use the DDT to create all of the stored procedures. If you take an existing SQL structure, the DDT will automatically import all structures, relationships, sprocs, and views. If you create a new table, you only need to check a single check box and the DDT will create the INSERT, UPDATE, and DELETE sprocs for you....without writing a single line of code. In fact, it even supports 3 different types of concurrency without requiring you, the developer, to do anything.

Second, you mentioned that the StrataFrame tutorial is only in VB.NET...this is not true. All samples, including the tutorial, come in both VB.NET and C#.

Third, you indicated that StrataFrame requires a connection string for each BO. This is very inaccurate. In StrataFrame you create a a DataSourceKey connection....you can have as many BOs use this one connection as needed. One major benefit of the StrataFrame connection strings is that is does NOT use a config file. This requires that your setup an XML tag and embed the connection strings within the assembly. There are even more advanced Connection String features regarding which include the Connection String Wizard and the Shared Settings WIzard. The Shared Settings file allows an encrypted connection string file to be created and placed in a shared location which any user can reference and retrieve all of the connection strings for an applicaiton (not on a per machine basis but rather in one location where all users pull their information). You can also define this manually, again without using a config file. In fact, if you attend the StrataFrame training or ask them, they can tell you about even more sophisticated ways that StrataFrame cann pull a connection string. For example, in their medical application they said that they have a Windows service that runs on a server and the clients automatically find that server using UDP which then gives them the connection string.

Finally, I would recommend talking to the StrataFrame developers as they are very accessible through their forum (http://forum.strataframe.net) and hopefully get some of this cleared up. I think it would be wise to revisit StrataFrame and learn more about what they do since you had some misunderstandings about the framework.

Cheers.

Ivan



>I have tried both Mere Mortals and Strataframe and found them very different. Strataframe's use of Themes makes impressive looking forms but I found their tools for building business objects, stored procedures, etc. cumbersome compared to Mere Mortals. Since I use xCase to create/maintained my SQL databases, Mere Mortals suits me better since it can create all the business objects in one step including classes for business rules, defaults, etc. It will also batch create all the stored procedures for CRUD on each table whereas with Strataframe you have to create them manually for each table. Since most of my apps have dozens of tables, this saves a lot of time.
>Strataframe has a lot of sample solutions and Mere Mortals is very limited in this respect. Being new to .NET, Strataframe might ease the learning curve especially since they have stated they will create sample apps for all frequently-asked questions. Strataframes use of Business Objects is more "visual" since they are dropped onto forms from the Toolbar and appear in the area below the form. The Strataframe tutorial is in VB.NET only and I like to see both VB and C# since I still haven't made up my mind which language I will use (although I am leaning towards C# for some reason). Mere Mortals has one entry for each databasekey in a config file to specify connection strings for all business objects where Strataframe specifies the connection string for each business object. All in all, they are very different but I am not qualified to say which is "better" especially since I have limited experience in .NET as well as the two frameworks. Individual's requirements are also very
>different for each developer.