I have a dataset table with various columns that are created during form load.
These columns are currently either system.double or system.string types.
And it is displayed in a datagridview.
This works fine.
But I need another column that can store a "list" or some collection in the data table.
A list of strings would do but a custom class would be better.
How is this usually done?
I have spent literally weeks googling this and I dont know where to start. The more I have looked the more confused I have ended up. I end up with more questions than answers, like how is it displayed in the datagridview? I read about a combo box?
I hope someone can give me some pointers in how to get this achieved. I've not posted any code as I think its more the theory of this I need help with.
What you are asking for has does have multiple concerns for most programmers. The storage of data (#1) and the displaying of said data to the user (#2)
For #1 I recommend the .net entity framework. It gives support for storing, querying and updating classes for use in the database. Through most tutorials that I have found it is possible to model the structure of the database tables and their relations and then build a database around that model OR to use an existing database and create entities (entity framework's class objects) around the existing structures and relationships.
Here is a link to a very good beginner tutorial that I have used before: CodeProject Entity Framework Tutorial for Absolute Beginners
For #2 I can recommend the Windows Presentation Foundation. It has lots of bells and whistles to make using a data source and displaying the relevant dependent data very easily through its unique method of data binding. From the tutorials I have used on PluralSight it can be as easy as dragging and dropping from an imported data source like the entity framework database. Alternatively, one can just handle selected row changes for one data grid and then show the dependent data in another data grid.
Related
I am quite new to Core Data, and I'm trying to implement it into my relatively simple OS X application. My application takes some file URLs provided by the user, gets some more information about the files (like creation date, for example), and then stores the URLs for use later.
I am wanting to have those file URLs, and related data, stored in a 'central' location so I can access, modify, and change the order of them (order is really important) from any of the classes in my application (correct me if I'm wrong, but I think Core Data is ideal for this).
I have my Core Data Model setup in Xcode (it only has one Entity which has a couple of Attributes), I've create an NSManagedObject Subclass to match the Entity in the Model, and I'm using Bindings to tie the data to a TableView. However, like I said, I need to be able get at this data from any class in my application. I have been reading Apple's Documentation and a book with a section on Core Data, however I am both struggling to get my head around it, and am yet to come across a section that describes the needs I mentioned above.
Any help with this (even just a link to a useful article) would be very much appreciated.
Thanks in advance.
My team is writing a large scale business website in ASP.NET MVC 4 using the database-first approach. Does anyone know if it's possible to have data annotations automatically generated based on the database schema? It seems redundant to have to manually write the "buddy" metadata classes containing the data annotations when the framework should be aware of a database column's properties and make these part of the POCO classes it generates. Any suggestions would be greatly appreciated!
Take a look at LINQ to SQL.
You can use it to create a .dbml file in a graphical editor by dragging the tables from the server explorer.
Here's the MSDN How to: Create LINQ to SQL Classes in a Web Project
1) The framework does a good job of extrapolating data annotation based on table structure, but they won't be perfect.
2) Sadly, when you reach a point when you want to customize more than the framework, you are stuck with Buddy classes. They're a bit tedious but so far the best method I've found for customizing data annotation.
3) All too often, I find myself gravitating toward custom classes and away from generated POCO's. The reason is usually the differences between storing and displaying. In entry screens
I will often break up phone #'s into 3 textboxes.
Lookups for foreign keys require select lists (often added to model).
Often I'll pass other values that may be relevant to my View functionality but not specific to the storage table (display fields, navigation / bread crumbs)
Use the Database First approach with the Entity Framework.
You can generate the entity model from an existing database using the entity data model wizard.
See http://msdn.microsoft.com/en-us/data/jj206878
#Kerezo covers pretty much exactly what you want to do here: Add Data Annotation To Entity Framework(Or Linq to SQL) generated class
It is not possible to auto generate the data annotations automatically.
I'm just starting to use Entity Framework Designer. I would like to ask how should I create my Entity files. I would like to have like 10 tables and all of them will be linked to at least one other table by some row. Should I create just one file and put all my models there or create a separate file for each model.
I don't know if this is even a question but I could find my answer on Google. I didn't know how to define it actually... :D
So if you have any tips on how I should model my database that will be awesome. Also if you have any more information on when I should use different Entity files that will be useful too.
I have used MySQL designer in the past but in there as far as i can remember you just move the model into the designer and you can make relations. So I'm kinda keen into doing that (all models in one Entity File) but wanted to check with you first guys.
just try this plugin for VS http://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d to generate your classes from existing db
I am creating a framework that works with Core Data. One of the requirements for using my framework on your Core Data class is that any entity you want to have the Framework's capabilities will need to be sub entities and sub classes of an entity I provide to you. For the sake of this I will call that object Foo.
Today I realized that Core Data stores all objects that are sub entities of Foo into a table called ZFOO. I'm worried about the performance of Core Data if someone with massive data sets wants to use it, since ALL sub entities of the foo class will be store in one enormous ZFOO table.
Any opinions or recommendations would be highly appreciated.
I worked with #deathbob on this project as the iOS lead. In our instance I had multiple classes which contained the attributes "remote_id" and "remote_update". I initially set the tables up using subclasses. I had a "RemoteEntity" abstract entity which contained those attributes and a bunch of other entities which inherited from it, each with their own. I thought that we would end up with a bunch of tables each with remote_id, remote_update, and then their custom attributes. Instead we ended up with the massive table you describe.
The fix was pretty simple you must not set up inheritance through the GUI. Instead include all attributes for that object including your shared ones in the Core Data modeller (this means "remote_id" and "remote_update" will appear in each entity. That being said we can still use a subclass. After generating your models' classes, create the parent entity's class. This must not be in the GUI. It should inherit from NSManagedObject and in the .m file the properties should use #dynamic instead of #synthesize. Now that you have the parent class it is time to adjust the child classes. Set the parent class to RemoteEntity (in my example) instead of NSManagedObject. Then remove any properties that appear in your super class (in my example, "remote_id" and "remote_update").
Here is an example of my super class https://gist.github.com/1121689.
I hope this helps, hat tip to #deathbob for pointing this out.
Last year I worked on a project that did the same thing, we stored everything in core data and everything in core data inherited from a single class which had some common attributes.
We had somewhere between 1k - 10k records in core data and performance degraded to the point where we rewrote it and removed the common ancestor. As I recall simple searches were taking multiple seconds, and insertions / updates were pretty crappy too. It was only after things had gotten painfully slow that we cracked the db open and noticed under the covers core data was storing everything in one table.
Sorry I don't remember specific numbers, the big takeaway was we had to redo it because it was too slow, and not too slow like too slow for high frequency trading but too slow like the app crashed on load when trying to populate the initial view out of core data.
So, with the grain of salt that this was on older iOS and older hardware, I would say definitely do not do this.
Hindsight is a wonderful thing.
As people are still reading this Q&A and referring to it in their questions and thinking that nothing has changed, I'd like to add a few comments for clarity and to provide a "modern" or more recent response.
Core data is a powerful beast, but you must learn to control the beast, and thanks to the pioneers who have answered previously and the improvements that Apple has made to the framework, it is a lot easier to do today than it was a couple of years ago (in particular iOS 5).
Initially I'd recommend learning how to prepare a solid and robust data model. There is a huge amount of information on this so I will leave it to the reader to investigate. As the previous answers mention, it is important to learn to prepare all relationships in the data model.
Beyond that, there are a number of mechanisms to control the size of data set you fetch. It has not been better explained to me than in a book from The Pragmatic Bookshelf – "Core Data, 2nd Edition, Data Storage and Management for iOS, OS X, and iCloud" (Jan 2013) by Marcus S. Zarra, and in particular Chapter 4 titled "Performance Tuning”.
Read it.
Good morning all.
I'm relatively new to the Visual Basic realm (although a traditional web based script developer), i've come to ask you a question. I am reading data from an XML file. This local XML file will be updated by another application, and I will need to periodically re-evaluate the XML file, and only import new data into a list box. Furthermore, I want to be able to click on a particular item in the listbox, and display the other values about that particular XML entry.
So, I suppose this is a multi part question. What is the proper way to import only NEW data into the program, what is the proper way to store the data, and how do I associate a value in a listbox with the data stored elsewhere?
I've considered multidimensional arrays, but have been told that strings to char arrays and then back to strings is a terrible way to manage the data, but was never offered an alternative.
I will be satisfied with a list of topics to study up on and/or an example for an answer to this question.
I would probably use classes that implement INotifyPropertyChanged and a BindingList. Then you just need to listen to ListChanged events off of the list and update the list box then.
I have a blog post that discusses binding classes and interfaces if you want to learn more about them: Data Binding Classes, Interfaces, and Attributes in Windows Forms 2.0. It might be a little dated by now, I haven't reviewed it since I wrote it in March, 2007.
As a start look at the XmlDocument and XmlReader classes.
http://msdn.microsoft.com/en-us/library/system.xml.xmldocument.aspx
http://msdn.microsoft.com/en-us/library/system.xml.xmlreader.aspx
XmlDocument helps load a document into memory and allows you to look at the document in any way you desire, depending on the size of the file there may be implications as to how long pulling in the file takes
XmlReader allows access on the fly, and gives you access very much like a DataReader. I.e. keeping track of your position in the dataset and not retaining any data once you have inspected it.
For keeping a track of updates, it depends where the XML is stored.
If it is in a file a FileSystemWatcher may help in determining when you need to update....
http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx