I am facing one problem. I am working on a project which has requirement of dynamically populating Grid control to add, update and remove records of specific table.
database is not finalized yet. so what i want is, if i add new column to a table and run the application. that grid should contain newly added column so that i can add new row. update or delete existing row.
I have crated DAL using LINQ to SQL but that is not covering my requirement. I want
Get name of tables from database and show them in dropdown list.
after selecting table name. grid should populate with all the columns. so that i can add/update/delete records.
So what exactly is your problem, you want to know how to get the table list from the database? If it is so, and if you're using SQL Server, you could run a select like that :
select name from sysobjects where xtype = 'U'
You can explore this system tables : sysobjects and syscolumns, they store the metadata information on the database.
From what I can gather, your best bet would be taking a different approach than Linq to SQL. You are looking for a UI which directly reflects your domain and can be generated automatically / dynamically. Two methods come to mind:
You can leverage MS Dynamic-Data which is an ASP.NET WebForms-based technology. You wire it up directly to a database or Entity Framework model. It generates the grids for all CRUD operations. It detects relationships via foreign keys and can generate the tables with links to one another. It's very customizable.
Dynamic Data
There is another architectural pattern called "Naked Objects". This requires rich, well-designed domain and aggregate roots. The UI should be 100% generated from this domain model. See the videos on this site to get a great example.
One example I can give you is, recently, our team has been divided - some working on an SOA application which integrates with our main product. Our developer resources are all focused on the task at hand writing WCF services, architecture, database engineering, ASP.NET, etc etc. We needed an internal application which we could use to administer the new SOA application. We could not dedicate another group of guys to build out a new application.
By using Dynamic Data, we had the entire administration app up and running off our EF 4 model in no time. It's doing everything we needed and minimal resources were exerted.
Use ADO.NET Entity Framework for your DAL than using LINQ TO SQL.
Well I solved this problem by getting table info from database schema.
build table to grid on run time which auto generates all columns.
created insert/update/delete query on fly by getting columns name from grid column name.
Happy coding:)
Related
I've hit a wall when it comes to adding a new entity object (a regular SQL table) to the Data Context using LINQ-to-SQL. This isn't regarding the drag-and-drop method that is cited regularly across many other threads. This method has worked repeatedly without issue.
The end goal is relatively simple. I need to find a way to add a table that gets created during runtime via stored procedure to the current Data Context of the LINQ-to-SQL dbml file. I'll then need to be able to use the regular LINQ query methods/extension methods (InsertOnSubmit(), DeleteOnSubmit(), Where(), Contains(), FirstOrDefault(), etc...) on this new table object through the existing Data Context. Essentially, I need to find a way to procedurally create the code that would otherwise be automatically generated when you do use the drag-and-drop method during development (when the application isn't running), but have it generate this same code while the application is running via command and/or event trigger.
More Detail
There's one table that gets used a lot and, over the course of an entire year, collects many thousands of rows. Each row contains a timestamp and this table needs to be divided into multiple tables based on the year that the row was added.
Current Solution (using one table)
Single table with tens of thousands of rows which are constantly queried against.
Table is added to Data Context during development using drag-and-drop, so there are no additional coding issues
Significant performance decrease over time
Goals (using multiple tables)
(Complete) While the application is running, use C# code to check if a table for the current year already exists. If it does, no action is taken. If not, a new table gets created using a stored procedure with the current year as a prefix on the table name (2017_TableName, 2018_TableName, 2019_TableName, and so on...).
(Incomplete) While the application is still running, add the newly created table to the active LINQ-to-SQL Data Context (the same code that would otherwise be added using drag-and-drop during development).
(Incomplete) Run regular LINQ queries against the newly added table.
Final Thoughts
Other than the above, my only other concern is how to write the C# code that references a table that may or may not already exist. Is it possible to use a variable in place of the standard 'DB_DataContext.2019_TableName' methodology in order to actually get the table's data into a UI control? Is there a way to simply create an Enumerable of all the tables where the name is prefixed with a year and then select the most current table?
From what I've read so far, the most likely solution seems to involve the use of a SQL add-on like SQLMetal or Huagati which (based solely from what I've read) will generate the code I need during runtime and update the corresponding dbml file. I have no experience using these types of add-ons, so any additional insight into these would be appreciated.
Lastly, I've seen some references to LINQ-to-Entities and/or LINQ-to-Objects. Would these be the components I'm looking for?
Thanks for reading through a rather lengthy first post. Any comments/criticisms are welcome.
The simplest way to achieve what you want is to redirect in SQL Server, and leave your client code alone. At design-time create your L2S Data Context, or EF DbContex referencing a database with only a single table. Then at run-time substitue a view or synonym for that table that points to the "current year" table.
HOWEVER this should not be necessary in the first place. SQL Server supports partitioning, so you can store all the data in a physically separate data structures, but have a single logical table. And SQL Server supports columnstore tables, which can compress and store many millions of rows with excellent performance.
I'm in the process of creating a piece of software that processes data on an existing SQL Server database (which I can't change).
I'm using visual studio to develop my application in C# using WPF and the MVVM framework.
Essentially, the main purpose of my program is to gather data from the several tables of the database and present it to the user in a meaningful way. I don't want to simply display the data in the tables, but instead to gather information spread over several tables and aggregate in a certain way.
For that purpose, I've already created several Views in the database (using SMSS), some of which are rather complicated.
My question is: should I map those Views in Entity Framework and use the created POCO class as the source of a Datagrid, or should I recreate those Views through a LINQ query? Secondly, can I use a list of anonymous type as the source of a datagrid, taking into account that it would, naturally, be read-only?
Thanks
First, if your views have no performance issues, you should map views to POCO. You do not need to recreate the wheels.
Secondly, you can bind a collection of anonymous type to source of a DataGrid, but anonymous type binding has a limitation of automatic column generation.
Background
I am starting a series of simple screens to display and update info in our ERP database.
I have worked through the wpf controls and understand the need for Observable Collections and after reading around on Entity Framework I understand the advantages of it sitting on top of ADO.net compared to the basic SQL methods and Datatables I am more comfortable with due to my SQL experience.
When I tried EF when I was first started working with Data CRUD screens I struggled to get the Observable Collections I needed, but having read this walk through last night ( https://msdn.microsoft.com/en-us/data/jj574514.aspx) and seen the notes for VS 2010 to edit EF code to get Observable Collections I think I want to try EF again.
Question
My Data screen needs present information which has be combined from five tables and a couple of sub views to be meaningful to the user.
Included in the dataview is a simple Y/N flag which comes from one of the five Datatables.
Can the user update the Y/N flag through the view mapped to EF, displayed in WPF datagrid ?
Or do I have to map all the base Datatables and sub views and recreate the view and Data Context in EF to allow the update to work?
If it is the latter does any one know of any tutorials or walk through I can use on my test development to try EF please
Thanks
The user can update a field via the view mapped to EF, however it is a little bit more complicated.
For a single table mapped to EF, the update is done by EF automatically, for a view mapped to EF you need to define the update function in the mapping details.
The function would be in form of an SQL stored procedure mapped to EF.
I'm having a hard time getting Entity Framework to do what I want it to do. I've got a form generator application that's already up and fully running in .NET WebForms. I've just begun the process of converting this over to use .NET MvC instead, with React as the view layer and Entity Framework to drive the database stuff.
One part of this application is intended to allow the users to add form controls to a list and have them laid out visually as they would be shown on the final published form. So you click on First Name, and it adds an input control with ID FirstName, header text above it, etc.
I've got the view layer set up to show some basic info about the controls and put them into a list. I've also already got all the database tables with the assembled information about various types of controls you can add to the page. My WebForms version of this manages all the relationships between various data tables and how that is packaged for the view layer through code.
I've been trying to use my existing tables in Entity Framework but haven't been able to get any of the foreign key relationships to work correctly. When I add them in MS SQL, they don't carry over and give me ways of accessing the data from the foreign tables via the objects representing a main table.
When I just leave the tables without any foreign key relationships in SQL itself
and add them to the model in Visual Studio, it also won't sync up the objects correctly. It will throw errors relating to missing mapping or that it can't find the data in the foreign objects.
So I've reached the point where I am importing all my tables, which does work correctly, but then I have to update the model for each table to add an object or collection of objects that can contain a reference to the corresponding matched foreign key data. Then I have to write procedures which will go through and set the object references themselves according to ID columns which already exist in the database (ControlType in Controls table matches up to ID in ControlTypes table, etc.).
Then if I make a change in the database and update the model, it will remove all the custom objects I've added to the model, and possibly throw more errors to boot if I've removed a column on the database. What a headache!
So I know that seems like a wall of text, but I'm at a loss for what to do. I'd like to just have a big data object that I can pass around for each control that contains all the related info pertinent to that particular control and can be used by React in my view layer to display the info.
An alternative to that is I could build in Ajax requests into the various components which would make database calls to get the info relevant to that particular portion of the control, but that seems like a huge pain.
Am I going about this all wrong or is EF really just this hard to use?
My situation is as follows. I'm using entity framework (4.0) in which I have defined a relatively simple model like, let's say, two entities:
user
transaction
A user can have multiple transactions in this scenario. When generating the database this would result (obviously) in 2 database tables names 'user' and 'transaction'.
The problem is that I want to use the code as a webservice where different companies should have their own environment (read: own users and transactions). A simple solution would be to add a column to both tables like, lets say 'company_id' to identify one user/transactions for companya from the user/transaction from companyb.
What I would like to have is a duplication of the tables like so:
compa_user
compa_transaction
compb_user
compb_transaction
This way..all data would be nicely separated and if company a generates a lot of transactions, company b would not notice that the system is getting slow or whatsoever.
My question: is there a way to accomplish this based on entity framework. So, can I have multiple tables representing one entity in my model and switch from table to table depending on which company is connecting to the service.
Any help appreciated!
If you really want to keep the tables seperate, then a seperate database for each client would be the easiest - only need to change the connection string in EF.
The other benefit of this model (seperate databases) is that the database will scale quite easily as each database could theoretically be on a different database server should the DB ever become the bottleneck.