Use 1:n DeleteActions - axapta

How is it possible to use DeleteActions for 1:n table-relations?
Example:
Table A ("id")
('foo')
,('bar')
,('blup')
Table B: ("id", "tableAId1", "tableAId2")
(1, 'foo', 'blup')
,(2, 'bar', 'foo')
I have two relations on tableB:
TableB:tableAId1 -> TableA:id
TableB:tableAId2 -> TableA:id
Both datasets in table B should be deleted, if 'foo' from table A is deleted.
I tried one delete-Action on table A, refering to table B with cascade-option, resulting in only dataset 1 in table B was deleted.
I tried two identical delete-Action on table A, refering to table B with cascade-option, resulting in table lock on database.
I know about overwriting delete() method on table A, but this isn't safe if using tableA.doDelete().

In AX 2009 and previous a delete action on a table only follows one of the relations (the first alphabetically sorted). A table should only be applied as a delete action once.
Your best choice then is to do your own cascade delete using delete_from in the delete method of your master table. If you do a doDelete, it will not delete the child records. Then just don't use the doDelete method!
In AX 2012 you explicitly specify which relation to follow on a delete action. You can apply the same table more than once, provided you specify different relations.
This is a nice feature, but is one of the reasons that table relations on the extended data types had to die.

Related

Data from Multiple Data Sources in One Column in Grid

I've been thrown quite the scenario today. Essentially, I have one table (ProjTransPosting) that houses records, and that table relates to a number of similarly structured tables (ProjCostTrans, ProjRevenueTrans, etc). They relate by TransId, but each TransId will relate to only one of the number of child tables (meaning if a TransId of 137 exists in ProjCostTrans, there cannot be a TransId of 137 in ProjRevenueTrans). The schemas of the children tables are identical.
So, my original thought was to create a Map and create the mappings from the various children tables. And then I would use this Map as a datasource in the form so everything can show up in one column. I created all the relationships between the Map and the children table along with the relation to the parent table. I put Map in the form as a datasource and this caused a blank Grid, although I don't know why. Is it the case that the Map object can only by of one table type at any given time? I thought the purpose of this was that it could be universal and act as a buffer to many record types. I'd like to pursue this route as this definitely would achieve what I'm looking for.
In failing this I was forced to arrange my Data Source to perform something like this: SELECT ProjTransPosting LEFT JOIN ProjCostTrans LEFT JOIN ProjRevenueTrans ... The problem with this is, each child table I add-on, it's creating additional columns, and the values of the other columns are all NULL (blank in AX). So I have something like this:
Parent.TransId ChildA.Field ChildB.Field ChildC.Field
1 NULL 1256 NULL
2 1395 NULL NULL
3 NULL 4762 NULL
4 NULL NULL 1256
Normally, the user would deal with the annoyance of having the extra columns show up, but they want to also be able to filter on the fields in all the children tables. My example above, they want to be able to filter "1256" and the results would return TransIds 1 and 4, but obviously since the values in this case are spread out in multiple columns, this cannot be done by the user.
Ideally the Map would "combine" these columns into one and then the user could filter easily on it. Any ideas on how to proceed with this?
Try creating a union query and then a view based on that query.
Maps are supposed to be used only in X++, and not as data sources in forms.
This sounds like the exact purpose of table inheritance in AX 2012.
http://msdn.microsoft.com/en-us/library/gg881053.aspx
When to use:
http://msdn.microsoft.com/en-us/library/gg843731.aspx
EDIT: Adding my comments here to make this a more full answer.
Let's say you have three tables TabPet, TabPetCat, TabPetDog, where TabPet is the supertype table and the others are decedents.
If you insert two records each into TabPetCat and TabPetDog (4 total), they will all have unique recIds. Let's say TabPetCat gets 5637144580 and 5637144581. TabPetDog gets 5637144582, and 5637144583.
If you open TabPet, you will see 5637144580, 5637144581, 5637144582, and 5637144583.
So what you would do is make your table ProjTransPosting the supertype and then ProjCostTrans, ProjRevenueTrans, etc descendant tables. Unless transId is really necessary, you could just get rid of it and only use RecId.

Cascading List of Values with many to many relationship

I am developing an application which tracks class attendance of students in a school, in Apex.
I want to create a page with three level cascading select lists, so the teacher can first select the Semester, then the Subject and then the specific Class of that Subject, so the application returns the Students who are enrolled in that Class.
My problem is that these three tables have a many-to-many relationship between them, so I use extra tables with their keys.
Every Semester has many Subjects and a Subject can be taught in many Semesters.
Every Subject has many classes in every Semester.
The students must enroll in a subject every semester and then the teacher can assign them to a class.
The tables look something like this:
create table semester(
id number not null,
name varchar2(20) not null,
primary key(id)
);
create table subject(
id number not null,
subject_name varchar2(50) not null,
primary key(id)
);
create table student(
id number not null,
name varchar2(20),
primary key(id)
);
create table semester_subject(
id number not null,
semester_id number not null,
subject_id number not null,
primary key(id),
foreign key(semester_id) references semester(id),
foreign key(subject_id) references subject(id),
constraint unique sem_sub_uq unique(semester_id, subject_id)
);
create table class(
id number not null,
name number not null,
semester_subject_id number not null,
primary key(id),
foreign key(semester_subject_id) references semester_subject(id)
);
create table class_enrollment(
id number not null,
student_id number not null,
semester_subject_id number not null,
class_id number,
primary_key(id),
foreign key(student_id) references student(id),
foreign key(semester_subject_id) references semester_subject(id),
foreign key(class_id) references class(id)
);
The list of value for the Semester select list looks like this:
select name, id
from semester
order by 1;
The the subject select list should include the names of all the Subjects available in the semester selected above, but I can't figure the query or even if it's possible. What I have right now:
select s.name, s.id
from subject s, semester_subject ss
where ss.semester_id = :PX_SEMESTER //value from above select list
and ss.subject_id = s.id;
But you can't have two tables in a LoV and the query is probably wrong anyway...
I didn't even begin to think about what the query for the class would look like.
I appreciate any help or if you can point me in the right direction so I can figure it out myself.
Developing an Apex Input Form Using Item-Parametrized Lists of Values (LOVs)
Your initial schema design looks good. One recommendation once you've developed and tested your solution on a smaller scale, append to the ID (primary key) columns a trigger that can auto-populate its values through a sequence. You could also skip the trigger and just reference the sequence in your sql insert DML commands. It just makes things simpler. Creating tables in the APEX environment with their built-in wizards offer the opportunity to make an "auto-incrementing" key column.
There is also an additional column added to the SEMESTER table called SORT_KEY. This helps when you are storing string typed values which have logical sorting sequences that aren't exactly alphanumeric in nature.
Setting Up The Test Data Values
Here is the test data I generated to demonstrate the cascading list of values design that will work with the example.
Making Dynamic List of Value Queries
The next step is to make the first three inter-dependent List of Values definitions. As you have discovered, you can reference page parameters in your LOVs which may come from a variety of sources. In this case, the choice selection from our LOVs will be assigned to Apex Page Items.
I also thought only one table could be referenced in a single LOV query. This is incorrect. The page documentation suggests that it is the SQL query syntax that is the limiting factor. The following LOV queries reference more than one table, and they work:
-- SEMESTER LOV Query
-- name: CHOOSE_SEMESTER
select a.name d, a.id r
from semester a
where a.id in (
select b.semester_id
from semester_subject b
where b.subject_id = nvl(:P5_SUBJECT, b.subject_id))
order by a.sort_id
-- SUBJECT LOV Query
-- name: CHOOSE_SUBJECT
select a.subject_name d, a.id r
from subject a
where a.id in (
select b.subject_id
from semester_subject b
where b.semester_id = nvl(:P5_SEMESTER, b.semester_id))
order by 1
-- CLASS LOV Query
-- name: CHOOSE_CLASS
select a.name d, a.id r
from class a, semester_subject b
where a.semester_subject_id = b.id
and b.subject_id = :P5_SUBJECT
and b.semester_id = :P5_SEMESTER
order by 1
Some design notes to consider:
Don't mind the P5_ITEM notation. The page in my sample app happened to be on "page 5" and so the convention goes.
I chose to assign a name for each LOV query as a hint. Don't just embed the query in an item. Add some breathing room for yourself as a developer by making the LOV a portable object that can be referenced elsewhere if needed.
MAKE a named LOV for each query through the SHARED OBJECTS menu option of your application designer.
The extra operator involving the NVL command, as in nvl(:P5_SUBJECT, b.subject_id) for the CHOOSE_SEMESTER LOV is an expression mirrored on the CHOOSE_SUBJECT query as well. If the default value of P5_SUBJECT and P5_SEMESTER are null when entering the page, how does that assist with the handling of the cascading relationships?
The table SEMESTER_SUBJECT represents a key relationship. Why is a LOV for this table not needed?
APEX Application Form Design Using Cascading LOVs
Setting up the a page for testing the schema design and LOV queries requires the creation of three page items:
Each page item should be defined as a SELECT LIST leave all the defaults initially until you understand how the basic design works. Each select list item should be associated with their corresponding LOV, such as:
The key design twist is the Select List made for the CHOOSE_CLASS LOV, which represents a cascading dependency on more than one data source.
We will use the "Cascading Parent" option so that this item will wait until both CHOOSE_SEMESTER and CHOOSE_SUBJECT are selected. It will also refresh if either of the two are changed.
YES! The cascading parent item can consist of multiple page items/elements. They just have to be declared in a comma separated list.
From the online help info, this is a general introduction to how cascading LOVs can be used in APEX designs:
From Oracle Apex Help Docs: A cascading LOV means that the current item's list of values should be refreshed if the value of another item on this page gets changed.
Specify a comma separated list of page items to be used to trigger the refresh. You can then use those page items in the where clause of your "List of Values" SQL statement.
Demonstration of APEX Application Items with Cascading LOVs
These examples are based on the sample data given at the beginning of this solution. The path of the chosen example case is:
SEMESTER: SPRING 2014 + SUBJECT: PHYS ED + Verify Valid Course Options:
Fitness for Life
General Flexibility
Presidential Fitness Challenge
Running for Fun
Volleyball Basics
The choice from above will be assigned to page item P5_CLASS.
Selection Choices for P5_SEMESTER:
Selection Choices for P5_SUBJECT:
Selection Choices for P5_CLASS:
Closing Remarks and Discussion
Some closing thoughts that occurred to me while working with this design project:
About the Primary Keys: The notion of a generic, ID named column for a primary key was a good design choice. While APEX can handle composite business keys, it gets clumsy and difficult to work around.
One thing that made the schema design challenging to work with was that the notion of "id" transformed in the other tables that referenced it. (Such as the ID column in the SEMESTER table became SEMESTER_ID in the SEMESTER_SUBJECT table. Just keep an eye on these name changes with larger queries. At times I actually lost track exactly what ID I was working with.
A Word for Sanity: In the likely event you decide to assign ID values through a database sequence object, the default is usually to begin at one. If you have several different tables in your schema with the same column name: ID and some associating tables such as CLASS_ENROLLMENT which connects the values of one primary key ID and three additional foreign key ID's, it may get difficult to discern where the data values are coming from.
Consider offsetting your sequences or arbitrarily choosing different increments and starting values. If you're mainly pushing ID's around in your queries, if two different ID sets are separated by two or three orders of magnitude, it will be easy to know if you've pulled the right data values.
Are There MORE Cascading Relationships? If a "parent" item relationship indicates a dependency that makes a page item LOV wait or change depending on the value of another, could there be another cascading relationship to define? In the case of CHOOSE_SEMESTER and CHOOSE_SUBJECT is it possible? Is it necessary?
I was able to figure out how to make these two items hold an optional cascading dependency, but it required setting up another outside page item reference. (If it isn't optional, you get stuck in a closed loop as soon as one of the two values changes.) Fancy, but not really necessary to solve the problem at hand.
What's Left to Do? I left out some additional tasks for you to continue with, such as managing the DML into the ENROLLMENT table after selecting a valid STUDENT.
Overall, you've got a workable schema design. There is a way to represent the data relationships through an APEX application design pattern. Happy coding, it looks like a challenging project!

Entity Framework hides n to n table

I have the following tables created using SQL Server management studio (I must not let EF create the DB because I need customized indexing along with something else).
Table A (AId)
Table B (BId)
Table AB(AId, BId)
There are foreign key constrains setup so A - B is a n-n relationship.
Now, when I import the model into EF, the relationship is displayed as * - * (which is correct), but Table AB is gone. This is not what I want! I want to have the ability to manually manage the relationship. How can I have EF show this table?
(the reason is the way EF manage relationship through strongly typed objects is counter performance - e.g. I want to manually create a B and link it to some As (I know the ID) without selecting those As and adding it in B's collection)
As Slauma stated it is possible to add a dummy field, but more importantly you can remove that dummy field and still have the link table.
Simple create the table AB, with an extra column called "Dummy" for example. Generate your model from this table. The table will now be included in the model.
Now got to the database and drop the "Dummy" column.
You can now either refresh the model from the database of simple delete the mapping for the "Dummy" column. You now have the link table in your EF model.
It's not possible to force EF to expose the link table as an entity when you create the model via database first - unless you change the schema in a way that EF does not consider the table as a pure many-to-many link table anymore, for example by adding a "dummy column" to the table. When you are using Code-First however, you can manually create an entity for the link table with two one-to-many relationships between A and AB and between B and AB.
I am not convinced by your argument why you want to do that...
I want to manually create a B and link it to some As (I know the ID)
without selecting those As and adding it in B's collection.
...because you don't need to load any entities from the database if you know the key values. You can use attached stub entities in order to create the relationships and write entries into the link table:
var newB = new B { As = new List<A>() };
foreach (var aId in someAIdCollection)
{
var existingA = new A { Id = aId };
context.As.Attach(existingA);
newB.As.Add(existingA);
}
context.Bs.Add(newB);
context.SaveChanges();
No database query is involved here and the resulting SQL commands are the same like inserting an AB link entity directly.

Oracle 11g express - Choose the position where a column is inserted?

Lets say I already have 3 columns A,B,C in my table Tb. I want to add a new column M between B and C. How can I do this ?
After adding M,my table should look like - A B M C and NOT A B C M ?
The simple answer is that you can't. Columns are always added at the end. However, you shouldn't care about the order of columns in a table since you should always be explicitly listing columns in your queries and in your DML. And you should always have an interface layer (a view, for example) where, if order is important, you can add the new column in the appropriate place.
If you are really determined, you can create a new table with the new column order, move the data to the new table, drop the old table, and rename the new table. You'll need to recreate any indexes, constraints, or triggers on the table. Something like
ALTER TABLE tb
ADD( M NUMBER );
CREATE TABLE tb_new
AS
SELECT a, b, m, c
FROM tb;
DROP TABLE tb;
ALTER TABLE tb_new
RENAME TO tb;
I'm not sure whether it's an option in the express edition (I tend to doubt it is but I don't have an XE database handy to verify) but you could also potentially use the DBMS_REDEFINITION package as Barbara shows in that example. Behind the scenes, Oracle is doing basically the same thing that is done above but with some added materialized view logs to allow applications to continue to access the table during the operation.
If you find yourself caring about the order of columns in a table, though, you're much better off stopping to figure out what you've done wrong rather than continuing to move forward on either path. It should be exceptionally, exceptionally rare that you would care about the physical order of columns in a table.

How should I go about making sure the value pairs in this table are unique?

I am using Visual Web Developer and Microsoft SQL server. I have a tag table "Entry_Tag" which is as follows:
entry_id
tag_id
I want to make the entry_id and tag_id pairing unique. A particular tag can only be applied to an entry once in the table. I made the two columns a primary key. They are also both foreign keys referencing the ids in their respective tables. When I dragged the tables into the Object Relationship Designer it only showed a relationship line between either "Entry_Tag" and "Entry" or when I tried again between "Entry_tag" and "Tag".
The "Entry_tag" table should have a relationship with both "Tag" and "Entry".
How do I go about doing this?
In general, you can add a unique constraint on the table that includes both columns. In this case, including both of the columns in the primary key should have already done this. If you have relationships set up for each field to other tables, then I believe those relationships should be displayed in the query designer... I see no cause for this given the information you've provided - perhaps you need to post more information.
Create an UNIQUE INDEX to for entry_id and tag_id.
CREATE UNIQUE INDEX index_name ON table (entry_id, tag_id)

Resources