One possible suspect for the behavior described could be object statefulness. If you are placing the recordset in a property of the object this may not be retained in between calls. Try receiving the existing rs as a parameter and returning the rs from your method instead of relying in a property.

Also in your second addnew call you wouldn't retrieve the rs from the source again, but just add a row to the existing rs. But I guess that's obvious.

Can't help you with the SharpGrid control problem. Hope it helps,

>Our application uses a middle layer of business objects to retreive data from SQL server and stores it for the client's use. Each object contains a property where we store the recordset. Once the data is populated, we return the object to the client. The client application then creates the appropriate form and sets the controlsources for the controls on the form to the fields in the recordset. We are experiencing a few problems that we hope someone will know how to correct. Keep in mind that if we create all of these object in development w/o using COM they work correctly.
>
>One of the problems occurs in our add new method. The method creates a new object via our COM server. When the business object is created on the COM server, it creates a blank recordset by calling the SQL Server view with a 'where' clause of 1=0. Next it adds a blank record to the recordset and populates some default values. Finally the object is returned to the client. At this point everything works correctly. However, if we select to add another new record, the object is passed back to the COM server and the recordset is blanked out again, but when we attempt to assign the default values to the fields we get an error : "recordset.FIELDS does not evaluate to an object".
>
>Another error occurs when we assign the recordset property of our business object as the controlsource for a Data Dynamics SharpGrid control. We have a command button on the form which returns the current id from the recordset. The data all displays correctly in the grid but it is not syncronized with the recordset. In development when the user selects a row on the grid and clicks the command button the recordset is on the same record as the grid control. However, if we use our COM server to return the business object and assign it's recordset as the grid's control source, then when the user clicks on the command button the recordset is always pointing at the first record rather than the one the user selected. This particuar error is complicated by the fact that it only occurrs when we're using a seperate machine as the COM server. If I compile and register the middle tier .DLLs on my local machine, the recordset syncs up correctly.
>
>We believe there is some problem that we're experiencing when we pass ADO recordsets between a COM server and our client application and we are hoping someone can shed some light on these problems.
>
>Jake