Hi Keith

What a well considered and thought out answer :)

It looks like the community in this forum is going to get as strong as the VFP forum.
Funny thing is I had not long posted in VFP chat saying how difficult it was to get .Net support.
Well your answer proves me wrong on that.

Thanks Again




>>Thank you
>>
>>This looks a very tidy way of doing things.
>>
>>Which of the following do you reccomend
>>
>>
>>1. Making these objects properties of the page.
>>
>
>This is the simplest way to get your application up and running. Technically, there's nothing wrong with making the objects properties of the page, but it may not be the most elegant solution and could cause you to have to do more work in the furture. See below.
>
>>2. Making these objects properties of a separate Session class
>>
>
>This method can possibly cause more problems than it solves. When you are dealing with a separate object, you have to manually control the creation and destruction of the object, as well as trap most application errors so that you don't have a large chunk of memory being wasted on an object that you no longer have a reference to. The garbage collector will eventually release the object, but it is possible that it will remain in memory for a long time before that happens.
>
>>3. Making these objects properties of the business object
>>
>
>This is the best long-term solution. If you already have a Business Objects layer, adding the data for these Entities is relatively simple. This would save many hours of work the next time you need to use the data in a different web form.
>
>In your example, you are storing the data in DataSets at the web form level, which is not really neccessary. It might be a good idea to invest some time creating your own classes to hold the data and perform some basic operations on the data. DataSets are huge memory hogs, and unless you have to enforce referential integrity at the web form level, there really is no need for all that extra overhead.
>
>Of course, you will probably use DataSets at some point to update and retreive the data from the database. When talking about Business Objects, it is implied that a Data Access layer is also a part of the equation. The DataSets belong in the Business Objects or Data Access layer. Your web forms pass information to and from the Business Objects layer using the lightweight classes I mentioned in the previous paragraph. The Business Objects layer then passes information to and from the Data Access layer using the same classes, or DataSets, depending on what kinds of referential integrity you want to enforce in the Business Objects layer. Finally, the Data Access layer integrates the changes into its DataSets and updates the database.
>
>Phew! That is a lot of information, but wait, there's more...
>
>We're talking about layers of a system and you might be tempted to equate these layers with physical locations like a Web Form or a Web Service. It ain't so! These layers can exist anywhere in the system. You could have the Business Objects layer and the Data Access layer reside in a Web Service, or you could even put all of the layers into your Web Form, which, of course, is not the best way to go about things. Most developers put the BO and DA layers into one Web Service, but a few will also put those layers into separate Web Services, which can be on different servers. Heck, you could even put the Data Access layer in a COM component that uses a database connection that remains open all the time.
>
>The reason for having this much complexity is that you gain total control of when the database gets updated and what data is sent to the database. You also gain the option of using any type of client with the data - Web Forms, Windows Forms, VFP or whatever. The primary goal of all of this work is to reduce the total amount of code that you will have to write over the lifetime of the system. Less code means less possible errors and more free time for you!
>
>My recommedation is to go with whatever option seems most appropriate given the scope of your project.
>
>Happy coding.
>
>>
>>Many Thanks
>>
>>
>>
>>
>>>To save the objects between round trips to the server, use Properties instead of Fields and use the Session state or View state as the backing:
>>>
>>>

>>>    Public Property dsAppName() As DataSet
>>>        Get
>>>            Return Session("dsAppName")
>>>        End Get
>>>        Set(ByVal Value As DataSet)
>>>            Session("dsAppName") = Value
>>>        End Set
>>>    End Property
>>>
>>>    Private Sub Page_Load(ByVal sender As System.Object, _
>>>        ByVal e As System.EventArgs) Handles MyBase.Load
>>>
>>>        If Not Page.IsPostBack Then
>>>            dsAppName = New DataSet()
>>>        End If
>>>    End Sub
>>>

>>>
>>>>My Save button does a postback before I get the chance to save to my table.
>>>>
>>>>The click event gets fired after the postback and by this time my daDataRow has vanished and I have to re=-create it.
>>>>
>>>>Having to re-create classes and variables in this manner seems a bit long winded :(
>>>>
>>>>Why does not the application on the server keep these public variables live for me.
>>>>
>>>>I know it can does this sort of thing because it can do it for shared properties/ methods quite happily. The big snag here is that shared P&Ms are GLOBAL! and all users worldwide get to share the same set of variables. In the main this is not desirable to say the least.
>>>>
>>>>At present I have things working, put the whole things still feels a bit Rube Goldberg/Heath Robinson to me.
>>>>