(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.
Related
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
Requirements
Here are the simplified requirements. The end goal is to be able to display data about an item, or print labels using the saved data. The solution is being created in Oracle Forms Builder
Attribute Definition form
Designed to define attributes.
Attribute configuration details are stored in an attribute
definition table
Attributes can be either a manually entered
values, or SQL driven
SQL Example: Case Weight (uses the Item's
Case UOM conversion rate multiplied by the item's unit weight)
Manual Example: Color of item
When SQL driven, a select statement is saved in the attribute configuration
Tokens like :INVENTORY_ITEM_ID are used in the SQL, and will be replaced with
values by the form when the SQL is evaluate.
Item Attribute Assignment form
Designed to link attributes to an item
Form includes a list of attributes assigned to an item
Records that link the attribute to the item are saved in the
database
Records store the attribute ID, Item ID and the attribute
value (if applicable)
List should be in a single block.
The form
allows additional assignments of attributes (which defined in first
form)
Items can have SQL and Manual type attributes assigned to
them.
Form allows "manual" values to be updated at any time by the
user
Form derives SQL values, displays them in the "value" field,
but the value field should be disabled so the user can't edit it.
Upon querying an item or assigning a new attribute
SQL values should be derived/evaluated
Manual entered values should be pulled
from the tables "value" column
Problem
We don’t want the form to save the SQL derived values to the table.
Is there a way to have a specific column on some rows not store a value in the database? These would be the rows that contain the SQL derived values, which are displayed in the disabled value cell, and derived when an item is queried, or an attributes is assigned.
It is possible, but you really should implement table handlers for your Forms, rather than relying on Oracle Forms to do your DML for you.
By "implement table handlers", I mean, set the block's "DML Data Target Type" property to "Use Transactional Triggers".
Then, code the ON-INSERT, ON-UPDATE, etc triggers for your block to call PL/SQL (passing in the appropriate values to insert, update, etc from your block).
In your PL/SQL, you can insert each column exactly where and how you want it, or don't insert a column at all, which is what you're after here.
If you are using the Oracle e-Business Suite, this is documented in the Oracle Applications Developer's Guide, chapter 10 ("Using PL/SQL in Oracle E-Business Suite: Coding Item, Event, and Table Handlers").
This is my first post ever and haven't come across any other questions related to this. I am attempting to try and create a hybrid validation type and add it to an existing oracle form. We have a super/subset type of thing going on. When one chooses something from a dropdown, there are 5 options. If 4 of those options are chosen, the data is pulled from one validation table dataset, table A. If the other option is chosen, it comes from a different table's dataset, table B. These (along with others items) are saved in Table C. Table C has a FK constraint regarding these validations. I have added another column to table C to attempt to bypass the FK constraint, but the field still tries to save in the FK column. I can't seem to figure out if I need to add a database trigger, an item level trigger, or a form level trigger to reroute the data to correct columns in the database. Thanks in advance for any help!
If your items are select lists, you would use an item level trigger (when-validate-item) on the superset list item to populate/repopulate the list for the subset item.
Alternatively, you could use a popup LOV on the subset item which has a query which is filtered by the value of the superset item.
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.
I created kendo ui grid.I am able to load the data from the database.For this grid the data is coming from different tables ,I used joins in my linq query to load the data.
Now,I want to update the data using linq query,and update the data in different tables.
Any suggestions..
You have to update individual records from each table and then execute db.SubmitChanges();
In your query the output is an anonymous type, not a table type connected to the dbContext.
If you think in terms of SQL, LinqToSql works very similar.
It´s possible to select a record set with a join, but you cannot update directly on this. You need to break it up and modify entries directly one by one.
A DataContext instance tracks all the instances it loads. When you call SubmitChanges, all of the changes are send to the database in one transaction.