Cardinality Enforcement

The Demo Headstart application has some cardinality
enforcement within Business Rule BR_EMP004_ENT
where there can be at most, one CLERK in a department.
This is enforced by an Aggregate function call in the
PL/SQL definition BR_EMP004_ENT. I assume that this
code was entered manually by a programmer.
Is there any way where I can set the Maximum Cardinality
on an Entity from within Designer and have Headstart
generate the Business Rule and/or the PL/SQL code to enforce
it?

Trevor,
Though it is possible to specify a maximum for an entities volume (entity property), this information is NOT used:
- by designer through one of its transformers/generators
- by CDM RuleFrame standard rule patterns
The BR you describe is slightly more complicated as it states the cardinality for a some records (only clerks, #<=4))
When you have many rules of this kind, CDM RuleFrame offers you the possibility to create a productivity booster that creates the code of these kind of rules for you, but you should write this utility yourself (do so only when it saves you time compared to entering those rules manually).
Kind regards,
Marc Vahsen
Headstart Team

Similar Messages

DM3.0 EA2: Logical Model Relation Cardinality:Source Optional mislabeled?

In logical model, created a 1:N non-identifying relation between 2 entities - Parent and Child. Parent is 1:N with Child. Both entities have a single column primary key - parent_id and child_id respectively. I would like to enforce RI such that a parent may exist with no children, but a child may not exist without a parent.
In the logical model the relation properties, cardinality - I modify the Source Optional and Target Optional checkboxes to achieve my desired result. I first tried checking Target Optional and leaving Source Optional un-checked. I then engineer a physical model and generate DDL for Oracle 11g I get this constraint:
SQL>ALTER TABLE child
2      ADD CONSTRAINT Relation_1 FOREIGN KEY
3      (
4       parent_id
5      )
6      REFERENCES parent
7      (
8       parent_id
9      )
10      ON DELETE SET NULL
11 ;
Table altered.Here's a test case illustrating this isn't quite what I wanted (starting with both tables empty):
SQL>
SQL>
SQL>insert into parent (parent_id) values (1);
1 row created.
SQL>commit;
Commit complete.
SQL>
SQL>insert into child (child_id, parent_id) values (901, 1);
1 row created.
SQL>commit;
Commit complete.
SQL>
SQL>delete from parent;
delete from parent
ERROR at line 1:
ORA-01407: cannot update ("ODS_ETL_OWNER"."CHILD"."PARENT_ID") to NULLIf I have Source Optional checked, and Target Optional not checked, engineer a physical model and generate DDL for Oracle 11g I get this constraint which produces the desired results with my test case:
SQL>ALTER TABLE child
2      ADD CONSTRAINT Relation_1 FOREIGN KEY
3      (
4       parent_id
5      )
6      REFERENCES parent
7      (
8       parent_id
9      )
10 ;
Table altered.
SQL>
SQL>insert into parent (parent_id) values (1);
1 row created.
SQL>commit;
Commit complete.
SQL>
SQL>insert into child (child_id, parent_id) values (901, 1);
1 row created.
SQL>commit;
Commit complete.
SQL>
SQL>delete from parent;
delete from parent
ERROR at line 1:
ORA-02292: integrity constraint (ODS_ETL_OWNER.RELATION_1) violated - child
record foundBut that seems backwards - and the documentation also reads as if it’s backwards. Am I missing something or are the Source Optional and Target Optional checkboxes mislabeled? Should they be Source Manditory and Target Manditory?

I would like to enforce RI such that a parent may exist with no children, but a child may not exist without a parent.You need to set parent as optional and child to be mandatory.
Am I missing something or are the Source Optional and Target Optional checkboxes mislabeled? Should they be Source Manditory and Target Manditory?There is a relationship and two ends of that relationship and you can set for each end whether it's optional or not. And that's seen directly using Barker notations. Source and target optionality place will be swapped on diagram if you use IE notation.
I expected that cardinality part could be more confusing for you because at source end you define cardinality of the target, but it seems you have no problem with that.
Philip

CBO - Wrong Cardinality Estimate

Hello,
Version 10.2.0.3
I am trying to understand the figures in the Explain Plan. I am not able to explain the cardinality of 70 on step 4.
The query takes very long to execute (about 400 secs). I would expect HASH JOIN SEMI instead of NESTED LOOPS SEMI.
I have tried to provide as much information as possible. I have just requested the 10053 trace, dont have it now.
There is a primary key on ORDERS.ORDER_ID (NUMBER) column. However, we are forced to use to_char(order_id) to accomodate for COT_EXTERNAL_ID being VARCHAR2 field.
1 select cdw.* from cdw_orders cdw where cdw.cot_external_id in
2 (
3 select to_char(order_id) from orders o where o.status_id in (12,16,22)
4* )
SQL> /
Execution Plan
Plan hash value: 733167152
| Id | Operation                     | Name                 | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                      |     2 |   280 |   326   (1)| 00:00:04 |
|   1 | NESTED LOOPS SEMI            |                      |     2 |   280 |   326   (1)| 00:00:04 |
|   2 |   TABLE ACCESS FULL           | CDW_ORDERS           | 3362 |   433K|   293   (1)| 00:00:04 |
|   3 |   INLIST ITERATOR             |                      |       |       |            |          |
|* 4 |    TABLE ACCESS BY INDEX ROWID| ORDERS               |    70 |   560 |     1   (0)| 00:00:01 |
|* 5 |     INDEX RANGE SCAN          | ORDERS_STATUS_ID_IDX |     2 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   4 - filter("CDW"."COT_EXTERNAL_ID"=TO_CHAR("ORDER_ID"))
   5 - access("O"."STATUS_ID"=12 OR "O"."STATUS_ID"=16 OR "O"."STATUS_ID"=22)Here is some of the details on the table columns and data.
SQL> select column_name,num_distinct,density,num_nulls,num_buckets from all_tab_columns where table_name = 'ORDERS'
2 and column_name in ('STATUS_ID','ORDER_ID');
COLUMN_NAME                    NUM_DISTINCT                        DENSITY NUM_NULLS NUM_BUCKETS
ORDER_ID                             177951             .00000561952447584          0         254
STATUS_ID                                23             .00000275335899280          0          23
SQL> select num_rows from all_tables where table_name = 'ORDERS';
NUM_ROWS
    177951
SQL> select index_name,distinct_keys,clustering_factor,num_rows,sample_size from all_indexes where index_name = 'ORDERS_STATUS_ID_IDX'
2 /
INDEX_NAME                     DISTINCT_KEYS CLUSTERING_FACTOR   NUM_ROWS SAMPLE_SIZE
ORDERS_STATUS_ID_IDX                      25             35893     177951      177951Histograms on column STATUS_ID
SQL> select * from (
2 select column_name,endpoint_value,endpoint_number- nvl(lag(endpoint_number) over (order by endpoint_value),0) count
3 from all_tab_histograms where column_name = 'STATUS_ID' and table_name = 'ORDERS'
4 ) where endpoint_value in (12,16,22);
COLUMN_NAME                    ENDPOINT_VALUE      COUNT
STATUS_ID                                  12        494
STATUS_ID                                  16         24
STATUS_ID                                  22       3064
SQL> select max(endpoint_number) from all_tab_histograms where column_name = 'STATUS_ID' and table_name = 'ORDERS' ;
MAX(ENDPOINT_NUMBER)
                5641I tried to run the query for individual values instead of inlist to check the numbers.
1 select cdw.* from cdw_orders cdw where cdw.cot_external_id in
2 (
3 select to_char(order_id) from orders o where o.status_id = 12
4* )
SQL> /
Execution Plan
Plan hash value: 3178043291
| Id | Operation                    | Name                 | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT             |                      |     2 |   280 |    33 (19)| 00:00:01 |
|   1 | MERGE JOIN SEMI             |                      |     2 |   280 |    33 (19)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| CDW_ORDERS           | 3362 |   433K|    21   (0)| 00:00:01 |
|   3 |    INDEX FULL SCAN           | CDW_ORD_COT_EXT_ID   | 3362 |       |     2   (0)| 00:00:01 |
|* 4 |   SORT UNIQUE                |                      | 15584 |   121K|    11 (46)| 00:00:01 |
|* 5 |    VIEW                      | index$_join$_002     | 15584 |   121K|     9 (34)| 00:00:01 |
|* 6 |     HASH JOIN                |                      |       |       |            |          |
|* 7 |      INDEX RANGE SCAN        | ORDERS_STATUS_ID_IDX | 15584 |   121K|     1   (0)| 00:00:01 |
|   8 |      INDEX FAST FULL SCAN    | PK_ORDERS            | 15584 |   121K|     5   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   4 - access("CDW"."COT_EXTERNAL_ID"=TO_CHAR("ORDER_ID"))
       filter("CDW"."COT_EXTERNAL_ID"=TO_CHAR("ORDER_ID"))
   5 - filter("O"."STATUS_ID"=12)
   6 - access(ROWID=ROWID)
   7 - access("O"."STATUS_ID"=12)For status_id = 12, the cardinality on step 7 for orders_status_id_idx is 15584 which is inline with the expectation ie., (494/5641)*177951 = 15583.7 ~ 15584.
Now, I continue the same with status_is = 16
1 select cdw.* from cdw_orders cdw where cdw.cot_external_id in
2 (
3 select to_char(order_id) from orders o where o.status_id = 16
4* )
SQL> /
Execution Plan
Plan hash value: 43581000
| Id | Operation                      | Name                 | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT               |                      | 1363 |   186K|    10 (10)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID   | CDW_ORDERS           |     2 |   264 |     1   (0)| 00:00:01 |
|   2 |   NESTED LOOPS                 |                      | 1363 |   186K|    10 (10)| 00:00:01 |
|   3 |    SORT UNIQUE                 |                      |   757 | 6056 |     2   (0)| 00:00:01 |
|   4 |     TABLE ACCESS BY INDEX ROWID| ORDERS               |   757 | 6056 |     2   (0)| 00:00:01 |
|* 5 |      INDEX RANGE SCAN          | ORDERS_STATUS_ID_IDX |   757 |       |     1   (0)| 00:00:01 |
|* 6 |    INDEX RANGE SCAN            | CDW_ORD_COT_EXT_ID   |     2 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   5 - access("O"."STATUS_ID"=16)
   6 - access("CDW"."COT_EXTERNAL_ID"=TO_CHAR("ORDER_ID"))Here also the cardinality on step 5 for orders_status_id_idx is as expected ie., (24/5641)*177951 = 757.1 ~ 757
Finally, running the same for status_id = 22 surprises me
1 select cdw.* from cdw_orders cdw where cdw.cot_external_id in
2 (
3 select to_char(order_id) from orders o where o.status_id = 22
4* )
SQL> /
Execution Plan
Plan hash value: 3496542905
| Id | Operation                    | Name                 | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT             |                      |     2 |   280 |   326   (1)| 00:00:04 |
|   1 | NESTED LOOPS SEMI           |                      |     2 |   280 |   326   (1)| 00:00:04 |
|   2 |   TABLE ACCESS FULL          | CDW_ORDERS           | 3362 |   433K|   293   (1)| 00:00:04 |
|* 3 |   TABLE ACCESS BY INDEX ROWID| ORDERS               |    60 |   480 |     1   (0)| 00:00:01 |
|* 4 |    INDEX RANGE SCAN          | ORDERS_STATUS_ID_IDX |     2 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   3 - filter("CDW"."COT_EXTERNAL_ID"=TO_CHAR("ORDER_ID"))
   4 - access("O"."STATUS_ID"=22)Like the ones for 12 and 16, I would have expected the cardinality on step 4 to be (3064/5641)*177951 = 96657, but I see only 2.
This is where my doubt is. Is this got to do with 22 being a popular value ? Can someone explain this behaviour ?
As a solution I am thinking of creating an index on to_char(order_id) - function based, hoping that the step 3 CDW.COT_EXTERNAL_ID = TO_CHAR(ORDER_ID) changes
to access instead of filter. Let me know your thoughts on the index creation as well.
Thanks,
Rgds,
Gokul
Edited by: Gokul Gopal on 24-May-2012 02:40

Hello Jonathan,
Apologies, I was wrong about optimizer_index_cost_adj value to be set to 100. I gather from DBA the value is set to currently set to 1.
I have pasted the 10053 trace file for value 22. I was not able to figure out the "jsel=min(1, 6.1094e-04)" bit.
/dborafiles/COTP/bycota2/udump/bycota2_ora_2147_values_22.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options
ORACLE_HOME = /dboracle/orabase/product/10.2.0
System name:     Linux
Node name:     byl945d002
Release:     2.6.9-55.ELsmp
Version:     #1 SMP Fri Apr 20 16:36:54 EDT 2007
Machine:     x86_64
Instance name: bycota2
Redo thread mounted by this instance: 2
Oracle process number: 37
Unix process pid: 2147, image: oracle@byl945d002 (TNS V1-V3)
*** 2012-05-28 14:00:59.737
*** ACTION NAME:() 2012-05-28 14:00:59.737
*** MODULE NAME:(SQL*Plus) 2012-05-28 14:00:59.737
*** SERVICE NAME:(SYS$USERS) 2012-05-28 14:00:59.737
*** SESSION ID:(713.51629) 2012-05-28 14:00:59.737
Registered qb: SEL$1 0x973e5458 (PARSER)
signature (): qb_name=SEL$1 nbfros=1 flg=0
    fro(0): flg=4 objn=51893 hint_alias="CDW"@"SEL$1"
Registered qb: SEL$2 0x973e6058 (PARSER)
signature (): qb_name=SEL$2 nbfros=1 flg=0
    fro(0): flg=4 objn=51782 hint_alias="O"@"SEL$2"
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM:   Checking validity of predicate move-around in SEL$1 (#0).
CBQT: Validity checks passed for 5r4bhr2yrt5gz.
apadrv-start: call(in-use=704, alloc=16344), compile(in-use=60840, alloc=63984)
Current SQL statement for this session:
select cdw.* from cdw_orders cdw where cdw.cot_external_id in (select to_char(o.order_id) from orders o where status_id = 22)
Legend
The following abbreviations are used by optimizer trace.
CBQT - cost-based query transformation
JPPD - join predicate push-down
FPD - filter push-down
PM - predicate move-around
CVM - complex view merging
SPJ - select-project-join
SJC - set join conversion
SU - subquery unnesting
OBYE - order by elimination
ST - star transformation
qb - query block
LB - leaf blocks
DK - distinct keys
LB/K - average number of leaf blocks per key
DB/K - average number of data blocks per key
CLUF - clustering factor
NDV - number of distinct values
Resp - response cost
Card - cardinality
Resc - resource cost
NL - nested loops (join)
SM - sort merge (join)
HA - hash (join)
CPUCSPEED - CPU Speed
IOTFRSPEED - I/O transfer speed
IOSEEKTIM - I/O seek time
SREADTIM - average single block read time
MREADTIM - average multiblock read time
MBRC - average multiblock read count
MAXTHR - maximum I/O system throughput
SLAVETHR - average slave I/O throughput
dmeth - distribution method
1: no partitioning required
2: value partitioned
4: right is random (round-robin)
512: left is random (round-robin)
8: broadcast right and partition left
16: broadcast left and partition right
32: partition left using partitioning of right
64: partition right using partitioning of left
128: use hash partitioning dimension
256: use range partitioning dimension
2048: use list partitioning dimension
1024: run the join in serial
0: invalid distribution method
sel - selectivity
ptn - partition
Peeked values of the binds in SQL statement
PARAMETERS USED BY THE OPTIMIZER
PARAMETERS WITH ALTERED VALUES
sort_area_retained_size             = 65535
optimizer_mode                      = first_rows_100
optimizer_index_cost_adj            = 25
optimizer_index_caching             = 100
Bug Fix Control Environment
fix 4611850 = enabled
fix 4663804 = enabled
fix 4663698 = enabled
fix 4545833 = enabled
fix 3499674 = disabled
fix 4584065 = enabled
fix 4602374 = enabled
fix 4569940 = enabled
fix 4631959 = enabled
fix 4519340 = enabled
fix 4550003 = enabled
fix 4488689 = enabled
fix 3118776 = enabled
fix 4519016 = enabled
fix 4487253 = enabled
fix 4556762 = 15
fix 4728348 = enabled
fix 4723244 = enabled
fix 4554846 = enabled
fix 4175830 = enabled
fix 4722900 = enabled
fix 5094217 = enabled
fix 4904890 = enabled
fix 4483286 = disabled
fix 4969880 = disabled
fix 4711525 = enabled
fix 4717546 = enabled
fix 4904838 = enabled
fix 5005866 = enabled
fix 4600710 = enabled
fix 5129233 = enabled
fix 5195882 = enabled
fix 5084239 = enabled
fix 4595987 = enabled
fix 4134994 = enabled
fix 5104624 = enabled
fix 4908162 = enabled
fix 5015557 = enabled
PARAMETERS WITH DEFAULT VALUES
optimizer_mode_hinted               = false
optimizer_features_hinted           = 0.0.0
parallel_execution_enabled          = true
parallel_query_forced_dop           = 0
parallel_dml_forced_dop             = 0
parallel_ddl_forced_degree          = 0
parallel_ddl_forced_instances       = 0
_query_rewrite_fudge                = 90
optimizer_features_enable           = 10.2.0.3
_optimizer_search_limit             = 5
cpu_count                           = 8
active_instance_count               = 2
parallel_threads_per_cpu            = 2
hash_area_size                      = 131072
bitmap_merge_area_size              = 1048576
sort_area_size                      = 65536
_sort_elimination_cost_ratio        = 0
_optimizer_block_size               = 8192
_sort_multiblock_read_count         = 2
_hash_multiblock_io_count           = 0
_db_file_optimizer_read_count       = 32
_optimizer_max_permutations         = 2000
pga_aggregate_target                = 602112 KB
_pga_max_size                       = 204800 KB
_query_rewrite_maxdisjunct          = 257
_smm_auto_min_io_size               = 56 KB
_smm_auto_max_io_size               = 248 KB
_smm_min_size                       = 602 KB
_smm_max_size                       = 102400 KB
_smm_px_max_size                    = 301056 KB
_cpu_to_io                          = 0
_optimizer_undo_cost_change         = 10.2.0.3
parallel_query_mode                 = enabled
parallel_dml_mode                   = disabled
parallel_ddl_mode                   = enabled
sqlstat_enabled                     = false
_optimizer_percent_parallel         = 101
_always_anti_join                   = choose
_always_semi_join                   = choose
_optimizer_mode_force               = true
_partition_view_enabled             = true
_always_star_transformation         = false
_query_rewrite_or_error             = false
_hash_join_enabled                  = true
cursor_sharing                      = exact
_b_tree_bitmap_plans                = true
star_transformation_enabled         = false
_optimizer_cost_model               = choose
_new_sort_cost_estimate             = true
_complex_view_merging               = true
_unnest_subquery                    = true
_eliminate_common_subexpr           = true
_pred_move_around                   = true
_convert_set_to_join                = false
_push_join_predicate                = true
_push_join_union_view               = true
_fast_full_scan_enabled             = true
_optim_enhance_nnull_detection      = true
_parallel_broadcast_enabled         = true
_px_broadcast_fudge_factor          = 100
_ordered_nested_loop                = true
_no_or_expansion                    = false
_system_index_caching               = 0
_disable_datalayer_sampling         = false
query_rewrite_enabled               = true
query_rewrite_integrity             = enforced
_query_cost_rewrite                 = true
_query_rewrite_2                    = true
_query_rewrite_1                    = true
_query_rewrite_expression           = true
_query_rewrite_jgmigrate            = true
_query_rewrite_fpc                  = true
_query_rewrite_drj                  = true
_full_pwise_join_enabled            = true
_partial_pwise_join_enabled         = true
_left_nested_loops_random           = true
_improved_row_length_enabled        = true
_index_join_enabled                 = true
_enable_type_dep_selectivity        = true
_improved_outerjoin_card            = true
_optimizer_adjust_for_nulls         = true
_optimizer_degree                   = 0
_use_column_stats_for_function      = true
_subquery_pruning_enabled           = true
_subquery_pruning_mv_enabled        = false
_or_expand_nvl_predicate            = true
_like_with_bind_as_equality         = false
_table_scan_cost_plus_one           = true
_cost_equality_semi_join            = true
_default_non_equality_sel_check     = true
_new_initial_join_orders            = true
_oneside_colstat_for_equijoins      = true
_optim_peek_user_binds              = true
_minimal_stats_aggregation          = true
_force_temptables_for_gsets         = false
workarea_size_policy                = auto
_smm_auto_cost_enabled              = true
_gs_anti_semi_join_allowed          = true
_optim_new_default_join_sel         = true
optimizer_dynamic_sampling          = 2
_pre_rewrite_push_pred              = true
_optimizer_new_join_card_computation = true
_union_rewrite_for_gs               = yes_gset_mvs
_generalized_pruning_enabled        = true
_optim_adjust_for_part_skews        = true
_force_datefold_trunc               = false
statistics_level                    = typical
_optimizer_system_stats_usage       = true
skip_unusable_indexes               = true
_remove_aggr_subquery               = true
_optimizer_push_down_distinct       = 0
_dml_monitoring_enabled             = true
_optimizer_undo_changes             = false
_predicate_elimination_enabled      = true
_nested_loop_fudge                  = 100
_project_view_columns               = true
_local_communication_costing_enabled = true
_local_communication_ratio          = 50
_query_rewrite_vop_cleanup          = true
_slave_mapping_enabled              = true
_optimizer_cost_based_transformation = linear
_optimizer_mjc_enabled              = true
_right_outer_hash_enable            = true
_spr_push_pred_refspr               = true
_optimizer_cache_stats              = false
_optimizer_cbqt_factor              = 50
_optimizer_squ_bottomup             = true
_fic_area_size                      = 131072
_optimizer_skip_scan_enabled        = true
_optimizer_cost_filter_pred         = false
_optimizer_sortmerge_join_enabled   = true
_optimizer_join_sel_sanity_check    = true
_mmv_query_rewrite_enabled          = true
_bt_mmv_query_rewrite_enabled       = true
_add_stale_mv_to_dependency_list    = true
_distinct_view_unnesting            = false
_optimizer_dim_subq_join_sel        = true
_optimizer_disable_strans_sanity_checks = 0
_optimizer_compute_index_stats      = true
_push_join_union_view2              = true
_optimizer_ignore_hints             = false
_optimizer_random_plan              = 0
_query_rewrite_setopgrw_enable      = true
_optimizer_correct_sq_selectivity   = true
_disable_function_based_index       = false
_optimizer_join_order_control       = 3
_optimizer_cartesian_enabled        = true
_optimizer_starplan_enabled         = true
_extended_pruning_enabled           = true
_optimizer_push_pred_cost_based     = true
_sql_model_unfold_forloops          = run_time
_enable_dml_lock_escalation         = false
_bloom_filter_enabled               = true
_update_bji_ipdml_enabled           = 0
_optimizer_extended_cursor_sharing = udo
_dm_max_shared_pool_pct             = 1
_optimizer_cost_hjsmj_multimatch    = true
_optimizer_transitivity_retain      = true
_px_pwg_enabled                     = true
optimizer_secure_view_merging       = true
_optimizer_join_elimination_enabled = true
flashback_table_rpi                 = non_fbt
_optimizer_cbqt_no_size_restriction = true
_optimizer_enhanced_filter_push     = true
_optimizer_filter_pred_pullup       = true
_rowsrc_trace_level                 = 0
_simple_view_merging                = true
_optimizer_rownum_pred_based_fkr    = true
_optimizer_better_inlist_costing    = all
_optimizer_self_induced_cache_cost = false
_optimizer_min_cache_blocks         = 10
_optimizer_or_expansion             = depth
_optimizer_order_by_elimination_enabled = true
_optimizer_outer_to_anti_enabled    = true
_selfjoin_mv_duplicates             = true
_dimension_skip_null                = true
_force_rewrite_enable               = false
_optimizer_star_tran_in_with_clause = true
_optimizer_complex_pred_selectivity = true
_optimizer_connect_by_cost_based    = true
_gby_hash_aggregation_enabled       = true
_globalindex_pnum_filter_enabled    = true
_fix_control_key                    = 0
_optimizer_skip_scan_guess          = false
_enable_row_shipping                = false
_row_shipping_threshold             = 80
_row_shipping_explain               = false
_optimizer_rownum_bind_default      = 10
_first_k_rows_dynamic_proration     = true
_optimizer_native_full_outer_join   = off
Bug Fix Control Environment
fix 4611850 = enabled
fix 4663804 = enabled
fix 4663698 = enabled
fix 4545833 = enabled
fix 3499674 = disabled
fix 4584065 = enabled
fix 4602374 = enabled
fix 4569940 = enabled
fix 4631959 = enabled
fix 4519340 = enabled
fix 4550003 = enabled
fix 4488689 = enabled
fix 3118776 = enabled
fix 4519016 = enabled
fix 4487253 = enabled
fix 4556762 = 15
fix 4728348 = enabled
fix 4723244 = enabled
fix 4554846 = enabled
fix 4175830 = enabled
fix 4722900 = enabled
fix 5094217 = enabled
fix 4904890 = enabled
fix 4483286 = disabled
fix 4969880 = disabled
fix 4711525 = enabled
fix 4717546 = enabled
fix 4904838 = enabled
fix 5005866 = enabled
fix 4600710 = enabled
fix 5129233 = enabled
fix 5195882 = enabled
fix 5084239 = enabled
fix 4595987 = enabled
fix 4134994 = enabled
fix 5104624 = enabled
fix 4908162 = enabled
fix 5015557 = enabled
PARAMETERS IN OPT_PARAM HINT
Column Usage Monitoring is ON: tracking level = 1
COST-BASED QUERY TRANSFORMATIONS
FPD: Considering simple filter push (pre rewrite) in SEL$1 (#0)
FPD:   Current where clause predicates in SEL$1 (#0) :
         "CDW"."COT_EXTERNAL_ID"=ANY (SELECT TO_CHAR("O"."ORDER_ID") FROM "ORDERS" "O")
Registered qb: SEL$1 0x974658b0 (COPY SEL$1)
signature(): NULL
Registered qb: SEL$2 0x9745e408 (COPY SEL$2)
signature(): NULL
Cost-Based Subquery Unnesting
SU: No subqueries to consider in query block SEL$2 (#2).
SU: Considering subquery unnesting in query block SEL$1 (#1)
SU: Performing unnesting that does not require costing.
SU: Considering subquery unnest on SEL$1 (#1).
SU:   Checking validity of unnesting subquery SEL$2 (#2)
SU:   Passed validity checks.
SU:   Transforming ANY subquery to a join.
Registered qb: SEL$5DA710D3 0x974658b0 (SUBQUERY UNNEST SEL$1; SEL$2)
signature (): qb_name=SEL$5DA710D3 nbfros=2 flg=0
    fro(0): flg=0 objn=51893 hint_alias="CDW"@"SEL$1"
    fro(1): flg=0 objn=51782 hint_alias="O"@"SEL$2"
Cost-Based Complex View Merging
CVM: Finding query blocks in SEL$5DA710D3 (#1) that are valid to merge.
SU:   Transforming ANY subquery to a join.
Set-Join Conversion (SJC)
SJC: Considering set-join conversion in SEL$5DA710D3 (#1).
Query block (0x2a973e5458) before join elimination:
SQL:******* UNPARSED QUERY IS *******
SELECT "CDW".* FROM "COT_PLUS"."ORDERS" "O","COT_PLUS"."CDW_ORDERS" "CDW" WHERE "CDW"."COT_EXTERNAL_ID"=TO_CHAR("O"."ORDER_ID") AND "O"."STATUS_ID"=22
Query block (0x2a973e5458) unchanged
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$5DA710D3 (#1).
PM:   Checking validity of predicate move-around in SEL$5DA710D3 (#1).
PM:     PM bypassed: Outer query contains no views.
JPPD: Applying transformation directives
JPPD: Checking validity of push-down in query block SEL$5DA710D3 (#1)
JPPD:   No view found to push predicate into.
FPD: Considering simple filter push in SEL$5DA710D3 (#1)
FPD:   Current where clause predicates in SEL$5DA710D3 (#1) :
         "CDW"."COT_EXTERNAL_ID"=TO_CHAR("O"."ORDER_ID") AND "O"."STATUS_ID"=22
kkogcp: try to generate transitive predicate from check constraints for SEL$5DA710D3 (#1)
predicates with check contraints: "CDW"."COT_EXTERNAL_ID"=TO_CHAR("O"."ORDER_ID") AND "O"."STATUS_ID"=22
after transitive predicate generation: "CDW"."COT_EXTERNAL_ID"=TO_CHAR("O"."ORDER_ID") AND "O"."STATUS_ID"=22
finally: "CDW"."COT_EXTERNAL_ID"=TO_CHAR("O"."ORDER_ID") AND "O"."STATUS_ID"=22
First K Rows: Setup begin
kkoqbc-start
            : call(in-use=1592, alloc=16344), compile(in-use=101000, alloc=134224)
QUERY BLOCK TEXT
select cdw.* from cdw_orders cdw where cdw.cot_external_id in (select to_char(o.order_id) from orders o where status_id = 22)
QUERY BLOCK SIGNATURE
qb name was generated
signature (optimizer): qb_name=SEL$5DA710D3 nbfros=2 flg=0
fro(0): flg=0 objn=51893 hint_alias="CDW"@"SEL$1"
fro(1): flg=0 objn=51782 hint_alias="O"@"SEL$2"
SYSTEM STATISTICS INFORMATION
Using NOWORKLOAD Stats
CPUSPEED: 714 millions instruction/sec
IOTFRSPEED: 4096 bytes per millisecond (default is 4096)
IOSEEKTIM: 10 milliseconds (default is 10)
BASE STATISTICAL INFORMATION
Table Stats::
Table: CDW_ORDERS Alias: CDW
    #Rows: 3375 #Blks: 1504 AvgRowLen: 132.00
Index Stats::
Index: CDW_ORD_COT_EXT_ID Col#: 10
    LVLS: 1 #LB: 232 #DK: 1878 LB/K: 1.00 DB/K: 1.00 CLUF: 1899.00
Index: CDW_ORD_REFERENCE_IDX Col#: 13
    LVLS: 0 #LB: 0 #DK: 0 LB/K: 0.00 DB/K: 0.00 CLUF: 0.00
Index: COMMITTED_IDX Col#: 12
    LVLS: 1 #LB: 171 #DK: 1673 LB/K: 1.00 DB/K: 1.00 CLUF: 1657.00
Index: OBJID_IDX Col#: 16 17
    LVLS: 2 #LB: 318 #DK: 3372 LB/K: 1.00 DB/K: 1.00 CLUF: 1901.00
Index: ORDID_IDX Col#: 14
    LVLS: 0 #LB: 0 #DK: 0 LB/K: 0.00 DB/K: 0.00 CLUF: 0.00
Table Stats::
Table: ORDERS Alias: O
    #Rows: 178253 #Blks: 7300 AvgRowLen: 282.00
Index Stats::
Index: IDX_ORDERS_CONFIG Col#: 80
    LVLS: 1 #LB: 215 #DK: 452 LB/K: 1.00 DB/K: 130.00 CLUF: 59161.00
Index: IDX_ORDERS_REFRENCE_NUMBER Col#: 6
    LVLS: 1 #LB: 428 #DK: 68698 LB/K: 1.00 DB/K: 1.00 CLUF: 115830.00
Index: ORDERS_BILLING_SI_IDX Col#: 13
    LVLS: 1 #LB: 84 #DK: 3049 LB/K: 1.00 DB/K: 8.00 CLUF: 27006.00
Index: ORDERS_LATEST_ORD_IDX Col#: 3
    LVLS: 0 #LB: 0 #DK: 0 LB/K: 0.00 DB/K: 0.00 CLUF: 0.00
Index: ORDERS_ORDER_TYPE_IDX Col#: 4
    LVLS: 2 #LB: 984 #DK: 64 LB/K: 15.00 DB/K: 932.00 CLUF: 59702.00
Index: ORDERS_ORD_MINOR__IDX Col#: 43 5
    LVLS: 2 #LB: 784 #DK: 112 LB/K: 7.00 DB/K: 375.00 CLUF: 42012.00
Index: ORDERS_OWNING_ORG_IDX Col#: 37
    LVLS: 0 #LB: 0 #DK: 0 LB/K: 0.00 DB/K: 0.00 CLUF: 0.00
Index: ORDERS_PARENT_ORD_IDX Col#: 2
    LVLS: 1 #LB: 206 #DK: 37492 LB/K: 1.00 DB/K: 1.00 CLUF: 58051.00
Index: ORDERS_SD_CONFIG__IDX Col#: 42
    LVLS: 2 #LB: 604 #DK: 10 LB/K: 60.00 DB/K: 3638.00 CLUF: 36389.00
Index: ORDERS_SPECIAL_OR_IDX Col#: 36
    LVLS: 1 #LB: 63 #DK: 2 LB/K: 31.00 DB/K: 556.00 CLUF: 1113.00
Index: ORDERS_STATUS_ID_IDX Col#: 5
    LVLS: 2 #LB: 635 #DK: 25 LB/K: 25.00 DB/K: 1440.00 CLUF: 36015.00
Index: PK_ORDERS Col#: 1
    LVLS: 1 #LB: 408 #DK: 178253 LB/K: 1.00 DB/K: 1.00 CLUF: 131025.00
SINGLE TABLE ACCESS PATH
Column (#5): STATUS_ID(NUMBER)
    AvgLen: 3.00 NDV: 20 Nulls: 0 Density: 2.7653e-06 Min: 2 Max: 33
    Histogram: Freq #Bkts: 20 UncompBkts: 5567 EndPtVals: 20
Table: ORDERS Alias: O
    Card: Original: 178253 Rounded: 95450 Computed: 95450.37 Non Adjusted: 95450.37
Access Path: TableScan
    Cost: 1419.89 Resp: 1419.89 Degree: 0
      Cost_io: 1408.00 Cost_cpu: 101897352
      Resp_io: 1408.00 Resp_cpu: 101897352
kkofmx: index filter:"O"."STATUS_ID"=22
Access Path: index (skip-scan)
    SS sel: 0.53548 ANDV (#skips): 60
    SS io: 419.81 vs. table scan io: 1408.00
    Skip Scan chosen
Access Path: index (SkipScan)
    Index: ORDERS_ORD_MINOR__IDX
    resc_io: 22918.81 resc_cpu: 204258888
    ix_sel: 0.53548 ix_sel_with_filters: 0.53548
    Cost: 5735.66 Resp: 5735.66 Degree: 1
Access Path: index (AllEqRange)
    Index: ORDERS_STATUS_ID_IDX
    resc_io: 19629.00 resc_cpu: 180830676
    ix_sel: 0.53548 ix_sel_with_filters: 0.53548
    Cost: 4912.53 Resp: 4912.53 Degree: 1
****** trying bitmap/domain indexes ******
Best:: AccessPath: TableScan
         Cost: 1419.89 Degree: 1 Resp: 1419.89 Card: 95450.37 Bytes: 0
SINGLE TABLE ACCESS PATH
Table: CDW_ORDERS Alias: CDW
    Card: Original: 3375 Rounded: 3375 Computed: 3375.00 Non Adjusted: 3375.00
Access Path: TableScan
    Cost: 292.51 Resp: 292.51 Degree: 0
      Cost_io: 291.00 Cost_cpu: 12971896
      Resp_io: 291.00 Resp_cpu: 12971896
Best:: AccessPath: TableScan
         Cost: 292.51 Degree: 1 Resp: 292.51 Card: 3375.00 Bytes: 0
OPTIMIZER STATISTICS AND COMPUTATIONS
GENERAL PLANS
Considering cardinality-based initial join order.
Permutations for Starting Table :0
Join order[1]: CDW_ORDERS[CDW]#0 ORDERS[O]#1
Now joining: ORDERS[O]#1
NL Join
Outer table: Card: 3375.00 Cost: 292.51 Resp: 292.51 Degree: 1 Bytes: 132
Inner table: ORDERS Alias: O
Access Path: TableScan
    NL Join: Cost: 4788284.86 Resp: 4788284.86 Degree: 0
      Cost_io: 4748144.00 Cost_cpu: 343916534896
      Resp_io: 4748144.00 Resp_cpu: 343916534896
kkofmx: index filter:"O"."STATUS_ID"=22
OPTIMIZER PERCENT INDEX CACHING = 100
Access Path: index (FullScan)
    Index: ORDERS_ORD_MINOR__IDX
    resc_io: 22497.00 resc_cpu: 217815366
    ix_sel: 1 ix_sel_with_filters: 0.53548
    NL Join: Cost: 19004464.41 Resp: 19004464.41 Degree: 1
      Cost_io: 18982134.75 Cost_cpu: 191314735126
      Resp_io: 18982134.75 Resp_cpu: 191314735126
OPTIMIZER PERCENT INDEX CACHING = 100
Access Path: index (AllEqJoin)
    Index: ORDERS_STATUS_ID_IDX
    resc_io: 1.00 resc_cpu: 7981
    ix_sel: 1.0477e-05 ix_sel_with_filters: 1.0477e-05
    NL Join: Cost: 1137.05 Resp: 1137.05 Degree: 1
      Cost_io: 1134.75 Cost_cpu: 19706236
      Resp_io: 1134.75 Resp_cpu: 19706236
****** trying bitmap/domain indexes ******
Best NL cost: 1137.05
          resc: 1137.05 resc_io: 1134.75 resc_cpu: 19706236
          resp: 1137.05 resp_io: 1134.75 resp_cpu: 19706236
adjusting AJ/SJ sel based on min/max ranges: jsel=min(1, 6.1094e-04)Semi Join Card: 2.06 = outer (3375.00) * sel (6.1094e-04)
Join Card - Rounded: 2 Computed: 2.06
SM Join
Outer table:
    resc: 292.51 card 3375.00 bytes: 132 deg: 1 resp: 292.51
Inner table: ORDERS Alias: O
    resc: 1419.89 card: 95450.37 bytes: 8 deg: 1 resp: 1419.89
    using dmeth: 2 #groups: 1
    SORT resource      Sort statistics
      Sort width:         598 Area size:      616448 Max Area size:   104857600
      Degree:               1
      Blocks to Sort:      65 Row size:          156 Total Rows:           3375
      Initial runs:         1 Merge passes:        0 IO Cost / pass:          0
      Total IO sort cost: 0      Total CPU sort cost: 10349977
      Total Temp space used: 0
    SORT resource      Sort statistics
      Sort width:         598 Area size:      616448 Max Area size:   104857600
      Degree:               1
      Blocks to Sort:     223 Row size:           19 Total Rows:          95450
      Initial runs:         2 Merge passes:        1 IO Cost / pass:        122
      Total IO sort cost: 345      Total CPU sort cost: 85199490
      Total Temp space used: 3089000
SM join: Resc: 2068.56 Resp: 2068.56 [multiMatchCost=0.00]
SM cost: 2068.56
     resc: 2068.56 resc_io: 2044.00 resc_cpu: 210418716
     resp: 2068.56 resp_io: 2044.00 resp_cpu: 210418716
SM Join (with index on outer)
Access Path: index (FullScan)
    Index: CDW_ORD_COT_EXT_ID
    resc_io: 2132.00 resc_cpu: 18119160
    ix_sel: 1 ix_sel_with_filters: 1
    Cost: 533.53 Resp: 533.53 Degree: 1
Outer table:
    resc: 533.53 card 3375.00 bytes: 132 deg: 1 resp: 533.53
Inner table: ORDERS Alias: O
    resc: 1419.89 card: 95450.37 bytes: 8 deg: 1 resp: 1419.89
    using dmeth: 2 #groups: 1
    SORT resource      Sort statistics
      Sort width:         598 Area size:      616448 Max Area size:   104857600
      Degree:               1
      Blocks to Sort:     223 Row size:           19 Total Rows:          95450
      Initial runs:         2 Merge passes:        1 IO Cost / pass:        122
      Total IO sort cost: 345      Total CPU sort cost: 85199490
      Total Temp space used: 3089000
SM join: Resc: 2308.37 Resp: 2308.37 [multiMatchCost=0.00]
HA Join
Outer table:
    resc: 292.51 card 3375.00 bytes: 132 deg: 1 resp: 292.51
Inner table: ORDERS Alias: O
    resc: 1419.89 card: 95450.37 bytes: 8 deg: 1 resp: 1419.89
    using dmeth: 2 #groups: 1
    Cost per ptn: 1.67 #ptns: 1
    hash_area: 151 (max=25600)   Hash join: Resc: 1714.08 Resp: 1714.08 [multiMatchCost=0.00]
HA cost: 1714.08
     resc: 1714.08 resc_io: 1699.00 resc_cpu: 129204369
     resp: 1714.08 resp_io: 1699.00 resp_cpu: 129204369
Best:: JoinMethod: NestedLoopSemi
       Cost: 1137.05 Degree: 1 Resp: 1137.05 Card: 2.06 Bytes: 140
Best so far: Table#: 0 cost: 292.5140 card: 3375.0000 bytes: 445500
             Table#: 1 cost: 1137.0501 card: 2.0619 bytes: 280
Number of join permutations tried: 1
(newjo-save)    [0 1 ]
Final - All Rows Plan: Best join order: 1
Cost: 1137.0501 Degree: 1 Card: 2.0000 Bytes: 280
Resc: 1137.0501 Resc_io: 1134.7500 Resc_cpu: 19706236
Resp: 1137.0501 Resp_io: 1134.7500 Resc_cpu: 19706236
kkoipt: Query block SEL$5DA710D3 (#1)
kkoqbc-end
          : call(in-use=156048, alloc=164408), compile(in-use=103696, alloc=134224)
First K Rows: Setup end
***********************

Enforcing a strategy plan to only produce one order in a single month

Hello All,
I have created a strategy plan that kicks out orders monthly, quarterly, semi-annually and annually. I have used the cycle unit of "MON", so orders get generated in cycles of 30 days. Everything is working great.
Now, here's a business requirement: only one order can be created in a single month. So, if this strategy kicks out an order on 01/01/09, and they complete it the same day, the next order will be created for 1/30/09. What is the most effective way to enforce SAP to only allow creation of one order in a single month?
Thank you for your help in advance.
Alex
Reference:
http://www.sapfans.com/forums/viewtopic.php?f=7&t=334722

Hi,
As Mr. Venu said along with the Key-date option the scheduling start date and call horizon is also important.
Reg,
NNR

ISE 1.2 - Posture Detail Assessment - enforcement audit mode report not show status for non-compliant

ISE 1.2 - Posture Detail Assessment - enforcement audit mode report not show status for non-compliant.
- For old version 1.1.4 it can be reported for non-compliant, How can I generate report for this?
Thanks
Kosin Usuwanthim

It used to be in there (id 226635 is the last one with it); should I clean it up a bit and put it back with a bit more of a disclaimer?

Unable to Enforce Unique Values, Duplicate Values Exist

I have list in SP 2010, it contains roughly 1000 items. I would like to enforce unique values on the title field. I started by cleaning up the list, ensuring that all items already had a unique value. To help with this, I used the export
to excel action, then highlight duplicates within Excel. So as far as I can tell, there are no duplicates within that list column.
However, when I try to enable the option to Enforce Unique Values, I receive the error that duplicate values exist within the field and must be removed.
Steps I've taken so far to identify / resolve duplicate values:
- Multiple exports to Excel from an unfiltered list view, then using highlight duplicates feature > no duplicates found
- deleted ALL versions of every item from the list (except current), ensured they were completely removed by deleting from both site and site collection recycle bins
- Using the SP Powershell console, grabbed all list items and exported all of the "Title" type fields (Item object Title, LinkTitle, LinkTitleNoMenu, etc) to a csv and ran that through excel duplicate checking as well.
Unless there's some rediculous hidden field value that MS expects anyone capable of attempting to enforce unique values on a list (which is simple enough for anyone to figure out - if it doesn't throw an error), then I've exhausted anything I can think
of that might cause the list to report duplicate values for that field.
While I wait to see if someone else has an idea, I'm also going to see what happens if I wipe the Crawl Index and start it from scratch.
- Jon

First, I create index for a column in list settings, it works fine no matter duplicate value exists or not;
then I set enforce unique values in the field, after click OK, I get duplicate values error message.
With SQL Server profiler, I find the call to proc_CheckIfExistingFieldHasDuplicateValues and the parameters. After reviewing this stored procedure in content database,
I create the following script in SQL Server management studio:
declare @siteid
uniqueidentifier
declare @webid
uniqueidentifier
declare @listid
uniqueidentifier
declare @fieldid
uniqueidentifier
set @siteid='F7C40DC9-E5D3-42D7-BE60-09B94FD67BEF'
set @webid='17F02240-CE04-4487-B961-0482B30DDA84'
set @listid='B349AF8D-7238-419D-B6C4-D88194A57EA7'
set @fieldid='195A78AC-FC52-4212-A72B-D03144DC1E24'
SELECT
* FROM TVF_UserData_List(@ListId)
AS U1 INNER
MERGE JOIN
            NameValuePair_Latin1_General_CI_AS
AS NVP1 WITH (INDEX=NameValuePair_Latin1_General_CI_AS_MatchUserData)
ON NVP1.ListId
= @ListId AND NVP1.ItemId
= U1.tp_Id
AND ((NVP1.Level
= 1 AND U1.tp_DraftOwnerId
IS NULL)
OR NVP1.Level
= 2)
AND NOT((DATALENGTH(ISNULL(NVP1.Value,
= 0)) AND U1.tp_Level
= NVP1.Level
AND U1.tp_IsCurrentVersion
= CONVERT(bit, 1)
AND U1.tp_CalculatedVersion
= 0 AND U1.tp_RowOrdinal
= 0 INNER
MERGE JOIN
            NameValuePair_Latin1_General_CI_AS
AS NVP2 WITH (INDEX=NameValuePair_Latin1_General_CI_AS_CI)
ON NVP2.SiteId
= @SiteId AND NVP2.ListId
= @ListId AND NVP2.FieldId
= @FieldId AND NVP2.Value
= NVP1.Value
AND NVP2.ItemId <> NVP1.ItemId
CROSS APPLY TVF_UserData_ListItemLevelRow(NVP2.ListId, NVP2.ItemId,
NVP2.Level, 0)
AS U2 WHERE ((NVP2.Level
= 1 AND U2.tp_DraftOwnerId
IS NULL)
OR NVP2.Level
= 2)
AND NOT((DATALENGTH(ISNULL(NVP2.Value,
= 0))
I can find the duplicate list items based on the result returned by the query above.
Note that you need to change the parameter values accordingly, and change the name of NameValuePair_Latin1_General1_CI_AS table based on the last parameter of the
proc_CheckIfExistingFieldHasDuplicateValues stored procedure. You can review the code of this stored procedure by yourself.
Note that direct operation on the content database in production environment is not supported, please do all these in test environment.

Cardinality estimator 2014 is off with OR in where clause

Here is my test setup on SQL Server 2014.
-- Create big table
CREATE TABLE [dbo].[Store](
Id int IDENTITY(1,1) NOT NULL,
City int NOT NULL,
Size int NOT NULL,
Name varchar(max) NULL,
CONSTRAINT [PK_Store] PRIMARY KEY CLUSTERED ([Id] ASC)
GO
CREATE NONCLUSTERED INDEX [IX_Store] ON [dbo].[Store] (City ASC, Size ASC)
GO
-- Fill with 100k rows
INSERT Store
SELECT i % 101, i % 11, 'Store ' + CAST(i AS VARCHAR)
FROM
(SELECT TOP 100000 ROW_NUMBER() OVER (ORDER BY s1.[object_id]) AS i
FROM sys.all_objects s1, sys.all_objects s2) numbers
GO
-- Create small table
CREATE TABLE #StoreRequest (City int NOT NULL, Size int NOT NULL)
GO
INSERT #StoreRequest values (55, 1)
INSERT #StoreRequest values (66, 2)
Now I execute the following query (I force the index to show statistics estimates)
SELECT s.City
FROM #StoreRequest AS r
INNER JOIN Store AS s WITH(INDEX(IX_Store), FORCESEEK)
ON s.City = r.City AND s.Size = r.Size
WHERE s.Size <> 1 OR r.City <> 55
Here are the estimates that I get (I'm not allowed to upload pictures):
Index Seek IX_Store
Actual Number of Rows: 90
Estimated Number of Rows: 50000
Fixing WHERE clause to use one table not two makes the estimate perfect:
SELECT s.City
FROM #StoreRequest AS r
INNER JOIN Store AS s WITH(INDEX(IX_Store), FORCESEEK)
ON s.City = r.City AND s.Size = r.Size
WHERE s.Size <> 1 OR s.City <> 55
Index Seek IX_Store
Actual Number of Rows: 90
Estimated Number of Rows: 89.74
Switching to 2012 compatibility mode gives estimate of 1 in both cases:
Index Seek IX_Store
Actual Number of Rows: 90
Estimated Number of Rows: 1
Could anyone explain the first result? I'm a bit worried about it. The fix in this case is trivial, but this problem gave us quite some headache in more complex real life queries with multiple joins.
Thank you!

But not full statistics on a field basis, just sometimes some default stats like total row count that some plans will build. Even your StoreRequest table only has one two-field index that will have a full histogram.
But I've seen SQL Server make massively bad plans on two-field indexes.
I've seen SQL Server go wrong one-column indexes, so that is not a very relevant point.
Temp tables or not, the estimate here is clearly incorrect. SQL Server knows the density of Size and City. It knows the cardinality of the temp table. The density information gives how many rows the the join will produce. The WHERE clause will then remove
a certain number of rows. With no statistics for the temp table, it does not now how many, but it will apply some standard guess.
50000 is a completely bogus number, because the join cannot produce that many rows, and SQL Server is able to compute the join with out the WHERE clause decently. (Well, it estimates 90, when the number is 180.) No, this is obviously a case of the cardinality
estimator giving up completely.
It is worth noting that both these WHERE clauses gives reasonable estimates:
WHERE r.Size <> 11 OR r.City <> 550
WHERE s.Size <> 11 OR s.City <> 550
Whereas these two gives the spooky 50000:
WHERE s.Size <> 11 OR r.City <> 550
WHERE r.Size <> 11 OR s.City <> 550
Erland Sommarskog, SQL Server MVP, [email protected]

Policy Enforcement issues in AM 7.1 with multiple user repositories

Hello,
We have a scenario where we need to authenticate and authorize both ADAM and Sun Directory Server users into a web application through the same realm. The realm is setup with 2 identity repositories - one for ADAM and one for DS - both of type LDAP v3 Repo. Authentication into AM console through the ?realm=name parameter works fine in this setup for users from both repositories.
However, when we try to authenticate users into the protected web application as an AD/DS user, policy enforcement is not deterministic. Policy Agent starts allowing URL access to DENIED users also. Is this a known issue/bug with Sun Access Manager 7.1?
The policy agents in our setup are Apache, Tomcat and IIS 6.
Thanks,
Srinivas

Please provide more information. If I understand you correctly, you have a realm with 2 LDAP Auth modules configured. Are these part of an Auth Chain? What does that Chain look like? Both Required? Sufficient?
What does your URL policy look like?
Have you made sure AM Agent is not set to SSO_ONLY?
What do you mean by "Policy Agent starts allowing URL access to DENIED users also"? You see "DENIED" in a log file but the user gets through, or you are just reporting the behavior?
Thanks,
Eric

How to enforce an order in which the Individual tabs are rendered in a tab navigator?

I have a TabNavigator with multiple tabs as below.
On the creationComplete event, the individual child elements are added as below.
xx.addElement(child1);
yy.addElement(child2);
zz.addElement(child3);
where
Bindable]
public var child1:Child1= new Child1();[
Bindable]
public var child2:Child2= new Child2();[
Bindable]
public var child3:Child3= new Child3();
Issue:
Is there a way to enforce the order in which these individual tabs are rendered? The order is not predictable and there is a dependency in the application that one of the tabs is already completed rendered before the other. Please let me know.
<mx:TabNavigator id="writTabs" x="9.7" y="290.35" width="696" height="466" fontWeight="normal"tabWidth="
90" >
<s:NavigatorContent id="debtorNc" label="Debtor" width="100%" height="100%" >
<view:WritDebtor id="writDebtor" width="695" height="432"/>
</s:NavigatorContent>
<s:NavigatorContent id="xx" width="100%" height="100%">
</s:NavigatorContent>
<s:NavigatorContent id="yy" width="100%" height="100%">
</s:NavigatorContent>
<s:NavigatorContent id="zz" width="100%" height="100%">
</s:NavigatorContent>
</mx:TabNavigator>
</s:Panel>

Try validateNow

How to enforce valid member combinations in Planning?

Hi,
Is it possible to enforce which combinations of members are valid in a Planning application? In Planning, each data cell represents the intersection of a member from each dimension. However, it is likely that not every combination of members is valid. For example, perhaps the combination of an Entity dimension member (like North Region) and an Account dimension member (like Salaries) should never exist because the North Region shoud not have data for Salaries. Is there a way to prevent data entry into the intersection of the North Region entity and Salaries account? Is there a way to define cross-dimension combination rules to prevent entry into cells that are defined to be invalid?
I currently have a Planning application that takes Actual data from another system, and the data coming from this system has defined member combinations that are allowed and not allowed. Is there a way I can define these same validation rules in the Planning application to maintain integrity and make sure that "impossible" combinations of data are not input into Planning? Thank you.

I am sorry to say that there is no way through Planning security to enforce combinations of members.
It's the nature of the OLAP beast below Planning's cover -- Essbase.
You can use security to restrict access to individual members, but cannot state "This Entity by these three Accounts only". What you can do is try to set up your forms so that this sort of metadata relationship shows up on the form -- attribute dimensions are often used to try to do this. It is an imperfect solution.
Regards,
Cameron Lackpour

What is line item dimension and cardinality in BI 7.0

Can u plz suggest me what is line item dimension and cardinality in BI 7.0..
Thanks in advance.
Venkat

Hi Babu
Line item: This means the dimension contains precisely one characteristic. This means that the system does not create a dimension table. Instead, the SID table of the characteristic takes on the role of dimension table. Removing the dimension table has the following advantages:
¡ When loading transaction data, no IDs are generated for the entries in the dimension table. This number range operation can compromise performance precisely in the case where a degenerated dimension is involved.
¡ A table- having a very large cardinality- is removed from the star schema. As a result, the SQL-based queries are simpler. In many cases, the database optimizer can choose better execution plans.
Nevertheless, it also has a disadvantage: A dimension marked as a line item cannot subsequently include additional characteristics. This is only possible with normal dimensions.
Note: In SAP BW 3.0, the term line item dimension from SAP BW 2.0 must a) have precisely one characteristic and b) this characteristic must have a high cardinality. Before, the term line item dimension was often only associated with a). Hence the inclusion of this property in the above. Be aware that a line item dimension has a different meaning now than in SAP BW2.0.
SAP recommends that you use ODS objects, where possible, instead of InfoCubes for line items.
Hope this helps.
Plz check these links:
SAP Help:
http://help.sap.com/saphelp_nw04s/helpdata/en/a7/d50f395fc8cb7fe10000000a11402f/frameset.htm
Thanks & Regards
Reward if helped
Edited by: Noor Ahmed khan on Aug 5, 2008 2:36 PM

Access Enforcer (error in creating a request)

Hi All,
when i am creating a new request in Access Enforcer . After filling alll the details and clicking the submit button it is showing a error in creating request .Path not found.

Hello,
You must have to select at least one condition attribute while creating your initiator. It seems initiator condition not meeting the details you are filling in your request. So it is not able to trigger the workflow initiator.
For simple scenario, if you are filling your company details in your request then change your initiator condition attribute to "Company".(Don't include more condition attributes for now). Once it works out then change initiator details back to your requirements.
Please let me know if this will not resolve your issue.
Thanks
Himadama

Using a strongly typed ref cursor doesn't enforce data type

I am trying to enforce the datatypes of the fields coming back from an oracle reference cursor by making it strongly typed. However, there seems to be no warning at compile time on the oracle side or exception in ODP.NET if the datatype coming back in the cursor does not match. For example here is my cursor and proc
create or replace
PACKAGE THIRDPARTY AS
type pricing_record is record
BaseIndexRate     number(6,5),
BaseIndexRateType     VARCHAR2(1 BYTE)
type cur_pricing2 IS ref CURSOR return pricing_record;
PROCEDURE getpricingbyappidtest(appid IN application.intid%TYPE, pricing OUT cur_pricing2);
END THIRDPARTY;
create or replace
PACKAGE BODY THIRDPARTY AS
PROCEDURE getpricingbyappidtest(appid IN application.appid%TYPE, pricing OUT cur_pricing2)
AS
BEGIN
     OPEN pricing FOR
     SELECT      somevarcharfield, someothervarcharfield
FROM application
WHERE A.appid = appid;
END getpricingbyappidtest;
I would expect this wouldn't compile since i am putting a varchar into a number field. But it does. Also if i check the datatype in the reader on the .net side it also is a string. So odp doesn't seem to care what type the cursor is
here is that code and output
var schemaTable = reader.GetSchemaTable();
using (var file = new System.IO.StreamWriter("c:\\_DefinitionMap_" + cursorName + ".txt"))
file.WriteLine("COLUMN" + "\t" + "DATATYPE");
foreach (DataRow myField in schemaTable.Rows)
file.WriteLine(myField["ColumnName"] + "\t" + myField["DataType"]);
COLUMN     DATATYPE
BaseIndexRate     System.String
BaseIndexRateType     System.String
Does anyone have an approach for enforcing datatypes in a ref cursor? Am I doing something wrong when defining the ref cursor?

Hello,
By using a ref cursor you are really using a pointer to a cursor. There is no way I know of to make a compile check of the cursor check unless you want to create a SQL type and cast the cursor to this type and even this wouldn't work in all cases. For instance, I could have function call within my cursor select which could return a varchar (with a number always in the varchar) which would be horribly sloppy but legal and you would expect Oracle to compile it.
If you are worried about this I would suggest not using ref cursors and go to UDT instead, where there will be more checking (because of a C# equivalence generated object). Oh and BTW, yes the cursor will throw an exception if the data is incorrect, but only at runtime - just like normal Oracle PLSQL.
Cheers
Rob.
http://www.scnet.com.au

Acrobat 9.3.4 doesn't enforce Date Formating

After we upgraded to Acrobat 9.3.4 from a previous version of 9.3 acrobat doesn't enforce date formating..before in a Text field formated as Date mm/dd/yyyy it would autocompelete if we typed in 9/21 to 9/21/2010.. now it doesn't, we can type any random text in the field and it isn't validated.
Ideas?

Just checked, its enabled.. when I say validate I'm referring to Acrobat's internal date format validation, not JavaScript.
For example if you create a text box, goto properties, format tab, format category = date, date options mm/dd/yyyy
now if you type:
"abcdef" in that text box it should say, "Invalid Date/time: please ensure that the date/time exists.
if you type 9/21 it will automatically turn it into 9/21/2010.
After Appling the 9.3.4 update no such validation takes place, any value entered is accepted..

Error while initiating Wily agent on SMD node of cardinality

Hi
I am not sure if I have to put this question here but anyways:
I have deployed wily agent thru JSPM and when tried to initiate it on SMD i get this error:
500 Internal Server Error
The initial exception that caused the request to fail, was:
com.sap.tc.webdynpro.progmodel.context.ContextException: Node(WilyAdmin.EMS): must not bind an empty collection to a Node of cardinality 1..1 or 1..n
Please suggest what can I do

Hi Bill,
I'm facing the same issue, did you resolve it?? If yes, how did you??
Best regards and thanks,
María Margarita Monteverde

Cardinality Enforcement

Similar Messages

Maybe you are looking for