OraFAQ Forum: SQL & PL/SQL » Materialized views to rescue "mutating tables"

Home » SQL & PL/SQL » SQL & PL/SQL » Materialized views to rescue "mutating tables" (release 1102000100)

Show: Today's Messages :: Polls :: Message Navigator
E-mail to friend

Materialized views to rescue "mutating tables" [message #598944]

Sun, 20 October 2013 12:22

Amine
Messages: 371
Registered: March 2010

Senior Member

Hi all,
We have some articles that we distribute to employees. Each article has a maximum number of existence.

drop table theo_life
/
create table theo_life
(
 id   int,
 nb_theo int
)
/
alter table theo_life add constraint PK_theo_life primary key (id);
insert into theo_life values (1, 1);
insert into theo_life values (2, 3);
insert into theo_life values (3, 1);

Here :
- article 1 should be distributed only once.
- article 2 should be distributed only 3 times.
Here is the table that connects people to articles :

drop table real_life
/
create table real_life
(
 pers   int,
 id   int
)
/
alter table real_life add constraint PK_real_life primary key (pers);
insert into real_life values (100, 1);
insert into real_life values (200, 2);
insert into real_life values (201, 2);
insert into real_life values (202, 2);
insert into real_life values (301, 3);
insert into real_life values (302, 3);

We want "real_life" to respect "theo_life"'s rules.
Meaning that rows with pers in (301,302) should not exist at the same time : id = 3 should exist at most once in real life.
Same thing for id = 2 : if we insert a new person with id = 2, this should provoke an error : id = 2 should exist at most 3 times in real life.
First solution that we think about is a before insert trigger : this will lead to a mutating table error. Solving this problem with an autonomous_transaction pragma will also lead to big problems in a multi user environment.
Second solution I think is to create a materialized view (mv_check_theo) based on this query :

select
real_life.id
, nb_theo
, count(*) nb_real
from real_life, theo_life
where real_life.id = theo_life.id
group by
real_life.id
, nb_theo
/

and to create a check constraint on it :

alter table mv_check_theo add constraint ck_theo check nb_real <= nb_theo novalidate;

Tried this with a failure :

SQL> create materialized view log on theo_life;

Materialized view log created.

SQL> create materialized view log on real_life;

Materialized view log created.

SQL> create materialized view mv_check_theo
  2  refresh fast
  3  on commit
  4  as
  5  select
  6  real_life.id
  7  , nb_theo
  8  , count(*) nb_real
  9  from real_life, theo_life
 10  where real_life.id = theo_life.id
 11  group by
 12  real_life.id
 13  , nb_theo
 14  /
from real_life, theo_life
     *
ERROR at line 9:
ORA-12032: cannot use rowid column from materialized view log on
"AMINE"."THEO_LIFE"


SQL>

My questions :
1. How to create this materialized view ?
2. Is this the right way to solve this kind of problems or are there better ?
Thanks in advance,
Amine

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #598950 is a reply to message #598944]

Sun, 20 October 2013 13:36

Michel Cadot
Messages: 68637
Registered: March 2007
Location: Nanterre, France, http://...

Senior Member
Account Moderator

Quote:

Second solution I think is to create a materialized view

You will not solve this problem with a mview.
And, once for all, forget autonomous_transaction pragma for anything but logging.
Or better, just forget it.

Regards
Michel

[Updated on: Sun, 20 October 2013 13:36]

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #598951 is a reply to message #598950]

Sun, 20 October 2013 14:46

Amine
Messages: 371
Registered: March 2010

Senior Member

Ok, so any suggestion Michel ?

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #598954 is a reply to message #598944]

Sun, 20 October 2013 15:11

Lalit Kumar B
Messages: 3174
Registered: May 2013
Location: World Wide on the Web

Senior Member

Amine wrote on Sun, 20 October 2013 22:52

Solving this problem with an autonomous_transaction pragma will also lead to big problems in a multi user environment.

Well, not only multi-user environment, it will also have the same issues with a single user as well. It has to do with transactions, and not with the number of users/sessions.

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #598955 is a reply to message #598954]

Sun, 20 October 2013 15:20

Amine
Messages: 371
Registered: March 2010

Senior Member

I am a little bit lost : The problem was solved through a procedure that we've created that does the necessary checks. This leads to let the real_life table in some wrong state according to the business rules. We run the procedure, detects the anomalies then perform the necessary update, delete to be back to a normal state.

Now the requirement changes and we want it to be at the transaction level. In that way, the real_life table ALWAYS moves from a correct state to another correct state.

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #598956 is a reply to message #598955]

Sun, 20 October 2013 16:49

DrabJay
Messages: 32
Registered: May 2013

Member

Although fast refreshable materialized views can be used for some complex multi-table constraint validation I don't think it is possible in this case as you cannot create a fast refreshable materialized view for this rule.

You can validate complex constraints via triggers but they need to be written very carefully in order to avoid the mutating table problem and issues with a database being a multi-user system.

For a detailed explanation of how this can be done I would suggest looking at the book Applied Mathematics for Database Professionals by Lex de Haan and Toon Koppelaars, and for an implementation of these principles try the RuleGen website.

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #598995 is a reply to message #598956]

Mon, 21 October 2013 05:16

Amine
Messages: 371
Registered: March 2010

Senior Member

it's really a big issue. And the solution might be using commercial tools...just look here

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #599011 is a reply to message #598956]

Mon, 21 October 2013 07:30

Solomon Yakobson
Messages: 3270
Registered: January 2010
Location: Connecticut, USA

Senior Member

DrabJay wrote on Sun, 20 October 2013 17:49

Although fast refreshable materialized views can be used for some complex multi-table constraint validation I don't think it is possible in this case as you cannot create a fast refreshable materialized view for this rule.

Yes, it is possible to create fast refresh on commit MV in this case:

create materialized view log on theo_life
with primary key,rowid,sequence(nb_theo)
including new values
/
create materialized view log on real_life
with rowid,sequence(id)
including new values
/
create materialized view mv_check_theo
  refresh fast
  on commit
  as
    select  real_life.id,
            nb_theo,
            count(theo_life.rowid) nb_real
      from  real_life,
            theo_life
      where real_life.id = theo_life.id
      group by real_life.id,
               nb_theo
/
alter table mv_check_theo
  add constraint ck_theo
  check (
         nb_real <= nb_theo
        )
/

For example:

SCOTT@orcl > drop table theo_life purge
  2  /

Table dropped.

SCOTT@orcl > create table theo_life(
  2                         id      int,
  3                         nb_theo int
  4                        )
  5  /

Table created.

SCOTT@orcl > insert into theo_life values(1,1)
  2  /

1 row created.

SCOTT@orcl > insert into theo_life values(2,3)
  2  /

1 row created.

SCOTT@orcl > insert into theo_life values(3,1)
  2  /

1 row created.

SCOTT@orcl > alter table theo_life
  2    add constraint PK_theo_life
  3      primary key(id)
  4  /

Table altered.

SCOTT@orcl > drop table real_life purge
  2  /

Table dropped.

SCOTT@orcl > create table real_life(
  2                         pers int,
  3                         id   int
  4                        )
  5  /

Table created.

SCOTT@orcl > alter table real_life
  2    add constraint PK_real_life
  3      primary key(pers)
  4  /

Table altered.

SCOTT@orcl > drop materialized view mv_check_theo
  2  /

Materialized view dropped.

SCOTT@orcl > drop materialized view log on theo_life
  2  /
drop materialized view log on theo_life
*
ERROR at line 1:
ORA-12002: there is no materialized view log on table "SCOTT"."THEO_LIFE"


SCOTT@orcl > drop materialized view log on real_life
  2  /
drop materialized view log on real_life
*
ERROR at line 1:
ORA-12002: there is no materialized view log on table "SCOTT"."REAL_LIFE"


SCOTT@orcl > create materialized view log on theo_life
  2  with primary key,rowid,sequence(nb_theo)
  3  including new values
  4  /

Materialized view log created.

SCOTT@orcl > create materialized view log on real_life
  2  with rowid,sequence(id)
  3  including new values
  4  /

Materialized view log created.

SCOTT@orcl > create materialized view mv_check_theo
  2    refresh fast
  3    on commit
  4    as
  5      select  real_life.id,
  6              nb_theo,
  7              count(theo_life.rowid) nb_real
  8        from  real_life,
  9              theo_life
 10        where real_life.id = theo_life.id
 11        group by real_life.id,
 12                 nb_theo
 13  /

Materialized view created.

SCOTT@orcl > alter table mv_check_theo
  2    add constraint ck_theo
  3    check (
  4           nb_real <= nb_theo
  5          )
  6  /

Table altered.

SCOTT@orcl > insert into real_life values(100,1)
  2  /

1 row created.

SCOTT@orcl > insert into real_life values(200,2)
  2  /

1 row created.

SCOTT@orcl > insert into real_life values(201,2)
  2  /

1 row created.

SCOTT@orcl > insert into real_life values(202,2)
  2  /

1 row created.

SCOTT@orcl > insert into real_life values(301,3)
  2  /

1 row created.

SCOTT@orcl > insert into real_life values(302,3)
  2  /

1 row created.

SCOTT@orcl > commit
  2  /
commit
*
ERROR at line 1:
ORA-12008: error in materialized view refresh path
ORA-02290: check constraint (SCOTT.CK_THEO) violated


SCOTT@orcl > select  *
  2    from  theo_life
  3  /

        ID    NB_THEO
---------- ----------
         1          1
         2          3
         3          1

SCOTT@orcl > select  *
  2    from  real_life
  3  /

no rows selected

SCOTT@orcl > select  *
  2    from  mv_check_theo
  3  /

no rows selected

SCOTT@orcl >

SY.

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #599027 is a reply to message #599011]

Mon, 21 October 2013 08:22

Amine
Messages: 371
Registered: March 2010

Senior Member

Well done Solomon. I am trying to follow this where Tom Kyte uses a DIY (Do It Yourself) trigger that preserves the business rule. Here is another equivalent problem. Thanks again Solomon.

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #599030 is a reply to message #599027]

Mon, 21 October 2013 08:43

Amine
Messages: 371
Registered: March 2010

Senior Member

Just a question Solomon :
- the MV's "on commit" is applied to theo_life, real_life or both ?

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #599037 is a reply to message #599030]

Mon, 21 October 2013 11:50

Solomon Yakobson
Messages: 3270
Registered: January 2010
Location: Connecticut, USA

Senior Member

Oops,

You are correct, it will not apply fast refresh when committing theo_life changes. And you can find it by using dbms_mview.explain_mview:

SCOTT@orcl > exec dbms_mview.explain_mview('mv_check_theo');

PL/SQL procedure successfully completed.

SCOTT@orcl > select capability_name,possible,msgtxt from mv_capabilities_table;

CAPABILITY_NAME                P MSGTXT
------------------------------ - --------------------------------------------------
PCT                            N
REFRESH_COMPLETE               Y
REFRESH_FAST                   Y
REWRITE                        N
PCT_TABLE                      N relation is not a partitioned table
PCT_TABLE                      N relation is not a partitioned table
REFRESH_FAST_AFTER_INSERT      Y
REFRESH_FAST_AFTER_ONETAB_DML  N COUNT(*) is not present in the select list
REFRESH_FAST_AFTER_ANY_DML     N see the reason why REFRESH_FAST_AFTER_ONETAB_DML i
                                 s disabled


CAPABILITY_NAME                P MSGTXT
------------------------------ - --------------------------------------------------
REFRESH_FAST_PCT               N PCT is not possible on any of the detail tables in
                                  the materialized view

REWRITE_FULL_TEXT_MATCH        N query rewrite is disabled on the materialized view
REWRITE_PARTIAL_TEXT_MATCH     N query rewrite is disabled on the materialized view
REWRITE_GENERAL                N query rewrite is disabled on the materialized view
REWRITE_PCT                    N general rewrite is not possible or PCT is not poss
                                 ible on any of the detail tables

PCT_TABLE_REWRITE              N relation is not a partitioned table
PCT_TABLE_REWRITE              N relation is not a partitioned table

16 rows selected.

Notice REFRESH_FAST_AFTER_ONETAB_DML = N because COUNT(*) is not present in the select list. That was my mistake. And as a result:

SCOTT@orcl > insert into real_life values(302,3)
  2  /

1 row created.

SCOTT@orcl > commit
  2  /
commit
*
ERROR at line 1:
ORA-12008: error in materialized view refresh path
ORA-02290: check constraint (SCOTT.CK_THEO) violated


SCOTT@orcl > update theo_life set nb_theo = 0
  2  /

3 rows updated.

SCOTT@orcl > commit
  2  /

Commit complete.

SCOTT@orcl >

As you can see, MV is not fast refreshed on committing theo_life changes. And since Oracle gave us a clue why, all I need is to change count(theo_life.rowid) to count(*). But there is another issue. What if we delete from theo_life? I assume there will be a FK for that. I also created a trigger on MV to show what's going on. Now:

SCOTT@orcl > drop table theo_life purge
  2  /

Table dropped.

SCOTT@orcl > create table theo_life(
  2                         id      int,
  3                         nb_theo int
  4                        )
  5  /

Table created.

SCOTT@orcl > insert into theo_life values(1,1)
  2  /

1 row created.

SCOTT@orcl > insert into theo_life values(2,3)
  2  /

1 row created.

SCOTT@orcl > insert into theo_life values(3,1)
  2  /

1 row created.

SCOTT@orcl > alter table theo_life
  2    add constraint PK_theo_life
  3      primary key(id)
  4  /

Table altered.

SCOTT@orcl > drop table real_life purge
  2  /

Table dropped.

SCOTT@orcl > create table real_life(
  2                         pers int,
  3                         id   int
  4                        )
  5  /

Table created.

SCOTT@orcl > alter table real_life
  2    add constraint PK_real_life
  3      primary key(pers)
  4  /

Table altered.

SCOTT@orcl > alter table real_life
  2    add constraint FK1_real_life
  3      foreign key(id)
  4      references theo_life
  5  /

Table altered.

SCOTT@orcl > drop materialized view mv_check_theo
  2  /

Materialized view dropped.

SCOTT@orcl > create materialized view log on theo_life
  2  with primary key,rowid,sequence(nb_theo)
  3  including new values
  4  /

Materialized view log created.

SCOTT@orcl > create materialized view log on real_life
  2  with primary key,rowid,sequence(id)
  3  including new values
  4  /

Materialized view log created.

SCOTT@orcl > create materialized view mv_check_theo
  2    refresh fast
  3    on commit
  4    as
  5      select  real_life.id,
  6              nb_theo,
  7              count(*) nb_real
  8        from  real_life,
  9              theo_life
 10        where real_life.id = theo_life.id
 11        group by real_life.id,
 12                 nb_theo
 13  /

Materialized view created.

SCOTT@orcl > alter table mv_check_theo
  2    add constraint ck_theo
  3    check (
  4           nb_real <= nb_theo
  5          )
  6  /

Table altered.

SCOTT@orcl > create or replace
  2    trigger mv_check_theo_biudr
  3      before insert
  4          or update
  5          or delete
  6      on mv_check_theo
  7      for each row
  8      begin
  9          if inserting
 10            then
 11              dbms_output.put_line(
 12                                   'INSERTING: id = ' || :new.id || ', nb_theo = ' ||
 13                                   :new.nb_theo || ', nb_real = ' || :new.nb_real
 14                                  );
 15          end if;
 16          if updating
 17            then
 18              dbms_output.put_line(
 19                                   'UPDATING: old id = ' || :old.id || ', old nb_theo = ' ||
 20                                   :old.nb_theo || ', old nb_real = ' || :old.nb_real ||
 21                                   ' new id = ' || :new.id || ', new nb_theo = ' ||
 22                                   :new.nb_theo || ', new nb_real = ' || :new.nb_real
 23                                  );
 24          end if;
 25          if deleting
 26            then
 27              dbms_output.put_line(
 28                                   'DELETING: id = ' || :old.id || ', nb_theo = ' ||
 29                                   :old.nb_theo || ', nb_real = ' || :old.nb_real
 30                                  );
 31          end if;
 32  end;
 33  /

Trigger created.

SCOTT@orcl > insert into real_life values(100,1)
  2  /

1 row created.

SCOTT@orcl > insert into real_life values(200,2)
  2  /

1 row created.

SCOTT@orcl > insert into real_life values(201,2)
  2  /

1 row created.

SCOTT@orcl > insert into real_life values(202,2)
  2  /

1 row created.

SCOTT@orcl > insert into real_life values(301,3)
  2  /

1 row created.

SCOTT@orcl > commit
  2  /
INSERTING: id = 1, nb_theo = 1, nb_real = 1
INSERTING: id = 2, nb_theo = 3, nb_real = 3
INSERTING: id = 3, nb_theo = 1, nb_real = 1

Commit complete.

SCOTT@orcl > insert into real_life values(302,3)
  2  /

1 row created.

SCOTT@orcl > commit
  2  /
UPDATING: old id = 3, old nb_theo = 1, old nb_real = 1 new id = 3, new nb_theo = 1, new nb_real = 2
commit
*
ERROR at line 1:
ORA-12008: error in materialized view refresh path
ORA-02290: check constraint (SCOTT.CK_THEO) violated


SCOTT@orcl > update theo_life set nb_theo = 0
  2  /

3 rows updated.

SCOTT@orcl > commit
  2  /
INSERTING: id = 1, nb_theo = 0, nb_real = 1
commit
*
ERROR at line 1:
ORA-12008: error in materialized view refresh path
ORA-02290: check constraint (SCOTT.CK_THEO) violated


SCOTT@orcl > insert
  2    into theo_life
  3    values(4,2)
  4  /

1 row created.

SCOTT@orcl > commit
  2  /

Commit complete.

SCOTT@orcl > select  *
  2    from  mv_check_theo
  3  /

        ID    NB_THEO    NB_REAL
---------- ---------- ----------
         1          1          1
         2          3          3
         3          1          1

SCOTT@orcl > insert
  2    into real_life
  3    values(55,4)
  4  /

1 row created.

SCOTT@orcl > commit
  2  /
INSERTING: id = 4, nb_theo = 2, nb_real = 1

Commit complete.

SCOTT@orcl > delete theo_life
  2  /
delete theo_life
*
ERROR at line 1:
ORA-02292: integrity constraint (SCOTT.FK1_REAL_LIFE) violated - child record found


SCOTT@orcl >

SY.

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #599048 is a reply to message #599037]

Mon, 21 October 2013 16:02

Amine
Messages: 371
Registered: March 2010

Senior Member

- Multi-user environment
- business rule enforced with elegance,
What to say more ?

This site is really tremendous !
Quality answers, quality persons !
Thanks Solomon and to every body that is participating to this site, making Orafaq among the best Oracle forums in the web !

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #599057 is a reply to message #599048]

Mon, 21 October 2013 20:43

Lalit Kumar B
Messages: 3174
Registered: May 2013
Location: World Wide on the Web

Senior Member

Amine wrote on Tue, 22 October 2013 02:32

- Multi-user environment
- business rule enforced with elegance,
What to say more ?

This site is really tremendous !
Quality answers, quality persons !
Thanks Solomon and to every body that is participating to this site, making Orafaq among the best Oracle forums in the web !

Well quoting this :

"a manager cannot manage more than 2 departments.",

is more of a reality.

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #599126 is a reply to message #599057]

Tue, 22 October 2013 06:05

Amine
Messages: 371
Registered: March 2010

Senior Member

Quote:

"a manager cannot manage more than 2 departments."

It's the same kind of problem. I think it could be done easily through a materialized view + check constraint.

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #599129 is a reply to message #599126]

Tue, 22 October 2013 06:36

Solomon Yakobson
Messages: 3270
Registered: January 2010
Location: Connecticut, USA

Senior Member

One thing you need consider before implementing it via materialized view is business requirements. Imagine lengthy business transaction app user has to go through just to find out at commit point there is a conflict and all that work was waste of time.

SY.

[Updated on: Tue, 22 October 2013 06:37]

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #599139 is a reply to message #599129]

Tue, 22 October 2013 08:18

Amine
Messages: 371
Registered: March 2010

Senior Member

I think that the most important thing is to keep the database safe from business rules errors, making things such reports sent to managers and decisions made by them with the minimum of errors. In that case, bad decisions taken by managers will be their errors rather than the database ones.

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #599141 is a reply to message #599139]

Tue, 22 October 2013 08:30

Solomon Yakobson
Messages: 3270
Registered: January 2010
Location: Connecticut, USA

Senior Member

Amine wrote on Tue, 22 October 2013 09:18

I think that the most important thing is to keep the database safe

Well, most important is to keep your company business profitable. You can (and you should) have database "fort Knox" safe, but if your customers are often running into a situation where issue is reported at the end after they fill out pages of info they will go to somewhere else. So it is both (and many more) things you must consider. And in many cases you have to compromise. And you know which way - customer is always right Laughing

Laughing

. Or consider data warehouse. You compromise enforcing data integrity rules for speed and make sure your ETL processes "behave" to honor data integrity.

SY.

[Updated on: Tue, 22 October 2013 08:32]

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #599571 is a reply to message #598950]

Sat, 26 October 2013 04:17

Amine
Messages: 371
Registered: March 2010

Senior Member

Michel Cadot wrote on Sun, 20 October 2013 19:36

You will not solve this problem with a mview.

Hi Michel,
Actually, it was solved through a materialized view + check constraint.

Regards,
Amine

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #599576 is a reply to message #599571]

Sat, 26 October 2013 06:09

Michel Cadot
Messages: 68637
Registered: March 2007
Location: Nanterre, France, http://...

Senior Member
Account Moderator

I don't know what has been done as I don't have time to analyse it but what I can say is each time someone thought he has a solution build on mview and/or trigger I always find a way to demonstrate it is not correct.

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #599584 is a reply to message #599576]

Sat, 26 October 2013 08:54

Amine
Messages: 371
Registered: March 2010

Senior Member

waiting then for the "counterattack" Smile

Smile

Always good to learn the pros and cons for doing something.

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #599585 is a reply to message #599584]

Sat, 26 October 2013 09:08

BlackSwan
Messages: 26766
Registered: January 2009
Location: SoCal

Senior Member

http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:9579487119866
where Tom said " when I hit a mutating table error, I've got a serious fatal flaw in my logic."

Mutating table is one way Oracle reports application design FLAW.
The application design should be changed so that mutating table does not occur.

[Updated on: Sat, 26 October 2013 09:09]

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #599586 is a reply to message #599585]

Sat, 26 October 2013 09:13

Amine
Messages: 371
Registered: March 2010

Senior Member

BS, you have the requirement and the needed tables : could you re-design what I gave so we won't have a mutating table error ?

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #599594 is a reply to message #599586]

Sat, 26 October 2013 12:15

Solomon Yakobson
Messages: 3270
Registered: January 2010
Location: Connecticut, USA

Senior Member

Even though MV solution will work here, personally (and I already mentioned that) I don't like reactive applications. I don't know all your application details, but I would explore sequences. For example, app can create a sequence with MAXVALUE = article count each time a new article set is created. Now all application needs is to get sequence nextval each time article is distributed to an employee and handle "NEXTVAL exceeds MAXVALUE" as "no more articles left". Obviously, it is not always that straight-forward. App might need to handle "returns" then it becomes a bit more complex.

SY.

Report message to a moderator

Re: Materialized views to rescue "mutating tables" [message #607447 is a reply to message #599576]

Thu, 06 February 2014 12:15

Amine
Messages: 371
Registered: March 2010

Senior Member

Hi Michel,
Just about your message, you mentioned that you can any solution based on mv to enforce business rules. How could you defeat this solution. Thanks in advance.

Report message to a moderator

Previous Topic:	Result from Rows to Columns
Next Topic:	user creation

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 16 19:02:24 CDT 2024