In the .NET framework, in order to save data into a databse item, one has to use:
Me.Validate();
Me.CustomersBindingSource.EndEdit();
Me.TableAdapterManager.UpdateAll(Me.CustomerDataSet);
Can someone explain me why? What's going on behind the scenes? If the .EndEdit() "applies changes to the underlying data source" why isn't it enough to apply those changes?
It is enough to "apply those changes"... to the data source. The data source is a DataTable, which is an object in your application. The UpdateAll call is what saves the changes from that DataTable - in fact, all DataTables in your DataSet - to the database.
ADO.NET is based on a disconnected model. That means that your application is not directly connected to your database. Using ADO in VB6, changes you made to a Recordset were made directly to the database. Not so in ADO.NET. When you call Fill, a connection to the database is opened, data is copied from the database into a DataTable and then the connection is closed. Any changes you make locally affect only that local copy. When you call Update or UpdateAll, the connection is opened again and the local changes saved to the database.
Related
I am struggiling with unexpected behavior in EntityFramework.
At first I display some data from DB on my screen. There is a possibility to modify this data. After I modify this data I SaveChangesAsync in DB (and they are there - I have checked in SQL Manager). And displayed data is OK until refresh, because then data displayed is right from before changes.
After await UnitOfWork.Complete (DBEntities context.SaveChangesAsync) I run DbSet.Where(predicates) and it returns old values.
I can provide some code if you need, just say what as there is plenty of it. Or ask me questions about what I did - I'll try to put it here.
Having code on each page to open a connection to retrieve or insert data to/from the local database can be very time consuming if you decide to change something (obviously having to change all of it so the code remains the same layout)
My question is, is it okay to have the connection to the database in the appCode. Is there a risk of to many connections the same source or from the same location?
I have a c# winform application that accesses data from a database (SQL Server CE), manipulates data and stores it back. I have been something rather "noobish", as in my program retrieves data from the .sdf file every time I need the data. Instead, I think it would be better to create a dataset which is populated from thae database when the application is launched. The changes can be made to the dataset, and then the dataset data can be stored back into the database when the application closes.
I want to know if this is the right way to go, or am I missing something. Note that the dataset exists only as long as the application is running.
I would suggest using SqlCeResultSet . It is suitable for displaying as well as updating data.
I'm trying to learn to use SQLite, but I'm very frustrated and confused. I've gotten as far as finding System.Data.SQLite, which is apparently the thing to use for SQLite in C#.
The website has no documentation whatsoever. The "original website", which is apparently obsolete from 2010 onwards, has no documentation either. I could find a few blog tutorials, but from what I can tell their method of operation is basically:
Initialize a database connection.
Feed SQL statements into the connection.
Take out stuff that comes out of the connection.
Close connection.
I don't want to write SQL statements in my C# code, they're ugly and I get no assistance from the IDE because I have to put the SQL code in strings.
Can't I just:
Create a DataSet.
Tell the DataSet that it should correspond to the SQLite database MyDB.sqlite.
Manipulate the DataSet using its member functions.
Not worry about SQLite because the DataSet automatically keeps itself in sync with the SQLite database on disc.
I know that I can fill a DataSet with the contents of a database, but if I want access to the entire database I will have to fill the DataSet with all of its contents. If my database is 1 GB, I have just used up 1 GB of RAM (not to mention the time needed to write all of it at once).
Can't I simply take a SQLite database connection and pretend it's just an ordinary DataSet (that perhaps needs to be asked occasionally if it's done syncing yet)?
The answer to the question is no.
No you cannot simply take a SQLite connection pretend it's just a DataSet.
If you don't want to code SQL statements then consider Entity Framework.
Using SQLite Embedded Database with Entity Framework and Linq-to-SQL
You shouldn't treat a DataSet as a database. It's just a result of a query.
You query the database to get a subset of data (you never want ALL the data from your DB) and this subset is used to populate your DataSet.
You are required to synchronize your changes manually because DataSet doesn't know which updates should be a part of which transaction. This is your system knowledge.
The DataSet is an in memory cache and will only synchronize to the underlying data store when the developer allows it. You could put a timer wrapper around in and do it on a schedule but you still need to keep the Dataset and data store synchronized manually.
Storing 1GB+ of data is really not recommended as the memory usage would be very high and the performance very low. You also don't want to be sending that amount of data over a network or god forbid an internet connection.
Why would you want to keep 1GB of data in memory?
I am binding a table in datagridview and I want that the user can edit the items in my form.Will the editing done here be updated in the sql server if i am using sql connection string.
That is doable as long as you're handling a proper PropertyChanged event for this type.
Aside, I would not recommend doing so, since this would necessitate to keep the connection alive until the whole editing is made, that is, one trip around the database for each property that has changed along the edit.
Should you want not to keep the connection, that will cost even more, since you'll have all the connection instantiation and opening overhead, yet your database engine might manage a connection pool for itself.
ADO.NET prefers an offline approach, I don't remember the term exactly. That is, connect to the database to load the needed data, and close and dispose it afterwards, so that another user may use the connection. Meanwhile, on your side, the user brings the changes he needs, then when he's done, he persists them into the database, and then only one trip around the database is required for a bunch of changes, which looks to me to be more productive and more performant.