linq for entities hide columns from model - c#

I am using linq for entities to read and update data from a SQL server. This database is a Dynamic NAV database, and every time someone is changing a column in the database – my application need to be recompiled.
Is it possible to ignore or hide columns in the database from linq for entities, and still get update to work correctly? Let’s say there is 100 columns in a table, and that I am using on only 10, when I update a value – I want the remaining 90 values to stay in the row.

You can just tell the people that add new columns to either
Allow null for newer columns
Or add a default constraint so a good default value is added automatically added for newer rows
Either of these will allow linq to work correctly

The best way would be to create a custom view in your database. If you want to be able to insert / update / delete from that view, you can create the appropriate triggers on the view. Linq will treat the view just like any other table.

Related

how to recognize newly added rows directly to datagridview - c#

I have bound a datatable to a datagridview and allowed the user to delete update, and insert new records directly to this datagridview
Now I want to know how do I recognize newly inserted row/rows ?
I want to get new row/rows and delete update, or insert them
into SQL server database.
How can I do it ?
Thanks
You can look into the DataTable.GetChanges method https://msdn.microsoft.com/en-us/library/thc1eetk
or better look into the DataAdapter.Update method https://learn.microsoft.com/en-us/dotnet/api/...
You can do it in 2 different ways - depend on your use case:
1st: Server side
Use this concept if you want to track the changes with multiple session per user, submit all changes to server side and track the changes datetime and save status.
2nd: Client side
Use this concept if you want to track the changes on client side regardless of the multi-session per user, basically, add 1 extra column to track the changes history -better to keep it hidden-

how can I take form names from SQLServer automatically

I want to add menu item from the database.
For example when I add a menu name into the database. It locates itself automatically.
Inside of the table, I have 3 columns.
ID, FormName, DisplayName.
How can I do it?
Thanks.
It isn't very clear what you mean, but: you can query the schema of tables either implicitly (select * from SomeTable, perhaps with a where 1=0, or there is a SET option to disable row returns) - then look at the IDataReader or DataTable or however else you're querying it to understand the layout; or perhaps better: by querying the meta-tables - INFORMATION_SCHEMA.COLUMNS etc. Once you know the column names and types, you can write a UI that does moderately suitable things based on that. If you need additional configuration, the "extended properties" feature of SQL Server allows you to store additional metadata against tables, columns, etc as name/value string pairs - essentially like [SomeAttribute(...)] in C#; for example, the MS_Description key/value pair is used by many UI tools to hold the descriptive label of a database entity (table, column, etc) - much like [Description("...")]. Putting all that together allows things to be barely tolerable by putting basic controls up to match each column/field with names and captions, but: a UI based on the raw database schema is usually very unsatisfying, and for most real work you'll want a custom UI with suitable logic and design considerations for the operation you're actually doing at the time.

ADO.NET: How to represent a selection of exactly one row from a table?

I have an ADO.NET DataSet that is persisted as XML. I need to add to it a list of cities and allow the user to select which city they're in. The selection has to be stored in the XML file along with the rest of the data.
This seems like a perfect use for DataSet.ExtendedProperties. However, it turns out that, in order for the extended properties to get written to the XML, I need to use XmlWriteMode.WriteSchema and XmlReadMode.ReadSchema, which adds the entire schema of the DataSet to the XML file just so it can add a single attribute, msprop:CityID.
My DataSet is strongly typed and its schema is hard-coded by the designer, so I really don't need to store the schema in the XML, which can lead to run-time errors.
So my question is, what's the best way to add the selected city to the DataSet itself. For example, using another table called SelectedCity, or using a Boolean column in the City table called IsSelected.
The SelectedCity table will always need to contain exactly one row, and the IsSelected column will need to contain true in exactly one row and false in all the others, and I don't know how to enforce such constraints in ADO.NET.
This seems like a fairly common scenario. What's the recommended way to code it?
If the relation is 1 to 1 put the field in the parent, but if a user can have various 1 to N put in another table. Sorry for my english.

Blank for new columns for old rows dynamodb

I am using c#.
I have thousands of rows in dynamodb like
Now I insert few more rows but with different columns
like
Here Row 3 and Row 4 are new rows
Now I need structure like below
Now I want old rows should have default 0 or blank string for new columns,
I don't want to iterate through old rows and updated items.
Is there any way to set default values..
What you're trying to achieve doesn't really work with NoSQL type databases. Technically, there is no concept of rows and columns when it comes to DynamoDB. Instead, there are items (your records) that contain any number of attributes. You can read more about it here.
If you're using an object mapper, I'd recommend dealing with this logic on that level, ie. when getting items from DynamoDB you can assign default values there if there is a need to do so.
This cannot be archived with a DynamoDB query. DynamoDB only "knows" about indexed keys (partition key, sort key and secondary indices) and is not able to tell you the name of all properties that exist in your table (unlike a relational database).
The only thing I can think of is:
Scan the entire database
Store all property names in e.g. a HashSet<T>
For each item: Add the missing properties, assing your default values and update it

Is it good to store static data in db - C#?

I have this problem and I don't know what is the best solution for it.
I have table called Employees and there is column called LastWork, this column should only have custom values I choose for example:
value 1
value 2
and I want the user to select the value from ComboBox control so I have 2 ideas for it but I don't know what is the best for it.
A - add these value to Combobox as string in Items property and store them as string in DB.
B - create separate table in my db called for example 'LastWork' with 2 columns 'LastWorkID', 'LastWorkName' and insert my values in it, and then I can add binding source control and I can use data bound items to store the id as integer in my main table and show the LastWorkName for users.
I prefer to use the B method because in some forms I have DataGridView control with edit permission, and I want to display Combobox in it instead of Textbox to select from these custom values.
I hope you understood my questions.
Normally data normalization is a good thing, so I too would go with your option B.
By having a separate table and a foreign key relationship to it, you can enforce data integrity; easily get a list of all available (not just all selected) options; have a single place in which to change the text of an option (what if someone decides to call it "value one" instead of "value 1", for example?); and so on and so forth.
These might not be huge benefits in a small application and with only two possible options, but we all know that applications very often tend to grow in scope over time.
In a normalized database, your "option B" is usually the way to go because it eliminates duplicate data. It will potentially introduce an additional join into your queries when you need the name (and not just the ID), but it also allows you to rename lookup names easily without altering their underlying IDs.
For performance reasons, it's often a good idea to cache lookup values such as you describe in the business tier so that your lookup table is not hit over and over again (such as when building many rows of a grid).
I would always save them in the db. If you have to localize your app, this helps alot. Additonally, it let you to apply the referential integrity checks of the database.

Categories

Resources