I guess part of my point is that all database access should use disconnected datasets. Typically you do not want your application to open a database connection and keep it open. You open the connection, grab the data into a DataSet and close the connection. Then, you pass that DataSet back to your UI where it gets worked on (data entry or whatever). Then, when you're ready to save whatever changes the user has made, you send the changes back through to the data access layer (via a DataSet) and then open your connection again, save the data, close your connection.

I suspect that you're talking about accessing the database and leaving the connection open the entire time the data is being used in the front-end UI. This is not good practice (and if I've mis-interpreted what you were saying, I apologize and please correct me).

~~Bonnie


>>>BTW, its better to use Stored Procedures to Add, update and delete records than using a datasets in your app. Don't rely on datasets...a bad design of using datasets to a database application may lead to user frustration on the application and to the developer :).
>>
>>I, respectfully, totally disagree with your suggestion that using DataSets is bad. It's the best way, IMHO, to work with disconnected data. I know, a lot of people say to do that all with Business objects, but I disagree.
>>
>>We grab our data from SQL Server directly into a DataSet and then pass that DataSet all the way back through the Business tier, the Web Service tier and back to the UI.
>>
>>~~Bonnie
>
>Hi Bonnie,
>
>Yes I know, it's the best way to work with disconnected data as datasets are designed for that reason. You may have use datasets the right way on your database application, if you can read my post with "a bad design of using datasets to a database application".
>
>BTW, what type of database application your saying here?
>
>Thanks..
>>
>>
>>
>>
>>>>Hi
>>>>I'm starting to use C# a fair bit now in Dot net, and am wondering if
>>>> there is any resource out there which has a 'Replacement' table for VFP v's C# commands, particualarly data commands
>>>>(I've got Dot Net for VFP Developers book and also had a look at the VFP toolkit for dot net. These do a good job but dont concentrate on Data type commands.
>>>>If theere was something like the following:
>>>>
>>>>VFP C#
>>>>--- ---
>>>>Seek = ???
>>>>Append Blank = ???
>>>>Replace = ???
>>>>Delete = ???
>>>>
>>>>I realise that the Dot net world is different (using Datasets, datareaders etc) but maybe there some useful info out there somewhere.
>>>>
>>>>regards,
>>>>Gerard
>>>
>>>
>>>Hi,
>>>
>>>Below are the equivalent of VFP to C#. For a clearer idea on this, read Mastering C# Database Programming.

>>>VFP             C#
>>>
>>>This are use in conjunction to Datasets, dataadapter, Datatable etc....
>>>
>>>>---             ---
>>>Seek          = FIND()-disadvantageous in record search,use STPROC/SQLSelect
>>>Append Blank  = Rows.Add()
>>>Replace       = UPDATE(DataTable)
>>>Delete        = RemoveDataRow.Delete()

>>>
>>>BTW, its better to use Stored Procedures to Add, update and delete records than using a datasets in your app. Don't rely on datasets...a bad design of using datasets to a database application may lead to user frustration on the application and to the developer :).