I am using typed datasets to retrieve and manipulate data. To generate a typed dataset I use the built-in dataset designer and drag-drop tables from data sources. In addition, mostly I need to add custom columns to my data tables.
The problem is that when I make a change in the underlying database schema I simply delete and regenerate the data table and loose all the custom columns that I added earlier. So everytime I regenerate a data table I had to add these custom columns again and again.
So my question is that if there is an easy way to mantain or keep track of these custom columns?
Don't delete the DataTable and regenerate it. Instead right-click, choose configure and adjust the query to add/remove your new columns. Then click finish and the table will be updated in the DataSet but without deleting your customisations.
Related
I'm new to oracle apex so this might be simple.
I have an application that i'm currently building. I have an 'employee' table in the SQL workshop. When i attempt to create a form linked to the table there is no option to edit, delete, or add entries into the table ,once the form is completed?
This is essentially what i need help with. I need to be able to manipulate the 'employee' table through the form created rather than through anything within the sql workshop. Just for context i am not the workspace admin, however i am a contributor.
I would appreciate if anyone could provide me with a quick step by step guide into creating this desired form accurately.
I'd suggest you to create (using the Wizard, of course) Report with Form on Table. It will create
interactive report you'd use to view data stored in that table
form which will be used to insert/update/delete data
the same form will be called when you push
the "Create" button in order to create new rows, or
icon at the beginning of every line in the report in order to update/delete rows
This combination (report + form) works nicely for ages, so ... try it. I hope you'll find it useful.
I have an application with a dataset linked to an sql server database. I have updated some of the names or foreign keys and primary keys in the sql server. How do I make those changes translate to the data set. For example, I had a primary key called fk_temsempl_xxxxx. I changed it to fk_temsempl on the sql database. How do I get that change to show in the dataset designer in visual studio?
I have tried running custom tool by right clicking on the dataset and clicking run custom tool. That didnt work. I tried configuring the table adapter of one of the tables where a change occured, but the name of the relation didnt change.
You actually just right click the relation and choose Edit Relation... or double click on the line (when the mouse cursor changes from arrow to drag symbol) but I honestly wouldn't bother; you'll then have further refactoring to do in the code anywhere the relation is used, and it can be heavily used by visual designers.
You also get the problem that VS may not help you with the refactoring: in data binding scenarios most things that can be a source of data can also be a collection of multiple things that can be a valid DataSource. They then rely on a string DataMember to determine which of the collections of data in the data source should be used for the data.
For example, when a bindingsource is bound to list a DataTable, the bindingsource.DataSource property might be the DataSet object that contains the DataTable, and thebindingsource.DataMemberis a string of "YOUR_TABLE_NAME". the BindingSource might not be bound asmyBindignSource.DataSource = myDataSet.MyDataTable`. Refactoring inside strings involves a find and replace
DataRelations in a DataSet are created from foreign keys as they were discovered when the relevant table(s) were added to the dataset but it is important to note that, like DataTables and everything else, they are NOTHING to do with the database schema objects at all - they aren't permanently associated with them, the dataset entities are just set up looking something like the database objects when they (dataset entities) are first created. DataTables are created from only those columns selected, and whatever .NET datatypes closely resemble the types output by the query. For a table of:
Person
------
Name VARCHAR(50)
SSN INTEGER
Birthdate DATE
If you created the table with SELECT * FROM Person you'd get a datatable with Name (string), SSN (int), Birthdate (datetime) but if you made a new datatable in the dataset based on SELECT LEFT(Name, 1) as Initial, PADLEFT(SSN, 20) as PadSSN, DATEDIFF(day, Birthdate, NOW()) as AgeDays FROM Person then you'd get a datatable of Initial (string), PadSSN (string), AgeDays (int) - i.e. the datatable looks nothing like the db table. This concept of disconnection between dataset and db is pervasive, and really the only things that relate in any way to the database are the properties that specify which DB table/column a particular DataTable/DataColumn relates to for purposes of loading/saving data. Your Person.Name datacolumn can be renamed to Blahblah, but it will still have a .SourceColumn property that is set to "Name" - that's how the mapping between dataset and db works; dataset is predominantly completely independent of the db. Renaming a DB column would require a change to the SourceColumn property only
DataRelations don't even have this notion of linking to the parent relation in the database; there's no SourceRelation or SourceFK proeprty because there is no need to. They're set up with the same rules and a generated name all based on the rules of the FK, but then they function independently and only within the dataset. If you rename or even remove an FK from the db the dataset will carry on working in the same restricted way it always did; adding a datarow to a child table when no aprent row exists for it will throw an exception - none of it anything to do with the FK in the db, and the DataRelation can have different rules to the FK (e.g it can cascade deletes when the FK is NOACTION) or even different columns. You can have more or fewer DataRelations than the DB has FKs
Run Custom Tool is not a "contact the DB and see what changes have occurred there and replicate them into the dataset", it is a "turn the XSD that describes the dataset into a bunch of C# classes that implement strongly typed dataset/table/relation/column etc objects". Any time you change the XSD by making an edit in the visual designer and hit save, the custom tool is run. If you edit the XSD directly in a text editor you may need to run it manually to have your changes reflected in c# classes
Reconfiguring a tableadapter probably won't do anything to the relations either; its solely concerned with changing the datatable and tableadapter. If you really want to refresh the relations, delete the datatable from the set and recreate it. Be prepared for a potentially significant mop up/refactoring of code
I would like to create a forms in my Access database which will save data to existing tables. This data entry form will save all valid data to the specified tables.
Now I would like to restrict the table from direct entry, i.e. no one can edit/update data directly in tables.
So please suggest me know can I do this.
You can not make something readonly AND not readonly. The forms need the tables to be writable.
What you can do is hide the tables, see: http://office.microsoft.com/en-gb/access-help/show-or-hide-database-objects-HP005188361.aspx.
If you need the tables for lookups you can make a readonly query based on the table. You have to change the query type to snapshot.
Im working on an online store project where I have already made it possible for an administrator to update different table entries via the store gui (like items, user profiles, orders etc). SaveChanges(); is used to save the changes.
Im currently trying to figure out how to make this work:
An entry in table "items" gets updated.
Before the entry in the table "items" gets updated, a copy of the old entry gets saved into a table named "history-items".
The copy that is saved to "history-items" preferably has a timestamp.
How would I go about doing this? (As you might tell, I just recently picked up visual studio, and am pretty new to everything)
Thank you.
There are atleast 3 ways to do this:
If you are using SQL Server 2008 or newer this is now built in functionality, see: http://msdn.microsoft.com/en-us/library/bb933994.aspx
If you opt not to use that then the simplest solution is to use database triggers.
If you want to do it in C# code, then you need to read the original values before saving, and save these original values to the history table. For reading original values see: How to get original values of an entity in Entity Framework?
I would go for option 1 if possible.
(VS2008) I'm trying to configure a TableAdapter in a Typed DataSet to return only a certain subset of columns from the main schema of the table on which it is based, but it always returns the entire schema (all columns) with blank values in the columns I have omitted.
The TableAdpater has the default Fill and GetData() methods that come from the wizard, which contain every column in the table, which is fine. I then added a new parameterized query method called GetActiveJobsByCustNo(CustNo), and I only included a few columns in the SQL query that I actually want to be in this table view.
But, again, it returns all the columns in the master table schema, with empty values for the columns I omitted.
The reason I am wanting this, is so I can just get a few columns back to use that table view with AutoGenerateColumns in an ASP.NET GridView. With it giving me back EVERY column i nthe schema, my presentation GridView contains way more columns that I want to show th user. And, I want to avoid have to declare the columns in the GridView.
When you add a new query to a given TableAdapter, it is going to assume the schema in which it is attached to, which is why you are getting blank values for the columns you don't want.
Since you mentioned having already created the procedure, what you need to do is use the Server Explorer to connect to the database and simply drag that stored procedure over into your XSD work area. What this will do is create a separate QueryAdapter that will have just the columns you specified (still strongly typed) and you can bind/interact with your GridView using that QueryAdapter instead.
Is the strongly typed dataset used in another query that returns all the rows from the table?
What you could do is create a dataview using the strongly typed dataset and expose a data table for your DataGridView.
I'm not sure what your requirements are totally, but this example should help you:
DataView dv = new DataView(ds.<Your_Table>);
// This will create a new data table with the same name,
// But with only two columns from the original table.
// This could then be bound to your data grid.
DataTable dt = dv.ToTable(false,
ds.<Your_Table>.<Your_Column1Column>.ColumnName,
ds.<Your_Table>.<Your_Column1Column>.ColumnName);
Just delete the columns you don't want at run-time before you bind to your Gridview. The underlying class is still just a DataTable after all.