Expected (wrong?) results from Express VI - a bug?

Using a Lab-Vierw supplied example made with express VIs fro signal egneration and ifltering.
MOdified the express VI so that instead of using a Butterworth lowpass it would use a Bessel with
variable order (variable # of poles).
Unexpecte result: when choose corbner freq = 1 KHz and drive with 1 KHz signal, I should get
output = 0.71 times input since at the corne freq, the output shuld be 3 dB down.
And I do get that result with a BUtterworth (all orders tried) or with a Bessel, if the Bessel is 1st order.
But for Bessel of order 2 or more, the attentiation is greater than expected, greater than it should be.
Bessel with Fc = 1000 Hz:
8 pole: Out/In = 0.18 when f=1000; Out/in=0.71 when f=500 Hz.
4 pole: Out/In = 0.39 when f=1000; Out/In = 0.71 when f=645 Hz.
2 pole: Out/In = 0.57 when f=1000; Out/In = 0.71 when f=790 Hz.
1 pole: Out/In = 0.71 when f=1000 as expected.
Is this a bug or is there another explanation?

The KB that I posted does show the transfer functions for the LabVIEW implementation of the Bessel functions. As WCR points out this does change what the cutoff frequency is actually referring to when using higher order Bessel filters. The LabVIEW help should reflect what the actual definition of the cutoff frequency for each filter, but it does not. I also checked the Chebyshev filter VIs and it does not refer to the ripple dB when specifying what the cutoff frequency is for that type of filter.
So, does the LabVIEW implementation of the higher order Bessel functions give results that might not be expected? Yes. Should the help files be updated to reflect this? Probably.
One thing that I did want to point out is that you can view the transfer functions used for the different types of filters using the Filter Express VI. If you open the configuration page and select the Transfer function as the View Mode, it will show how the transfer function looks for each filter. If you select Butterworth, you can increase the order and see it lock on the -3 dB point. If you select Bessel, you can increase the order and watch the curve shift to the left, decreasing the dB values at the cutoff frequency.
Andy F.
National Instruments

Similar Messages

Select for update gives wrong results. Is it a bug?

Hi,
Select for update gives wrong results. Is it a bug?
CREATE TABLE TaxIds
TaxId NUMBER(6) NOT NULL,
LocationId NUMBER(3) NOT NULL,
Status NUMBER(1)
PARTITION BY LIST (LocationId)
PARTITION P111 VALUES (111),
PARTITION P222 VALUES (222),
PARTITION P333 VALUES (333)
ALTER TABLE TaxIds ADD ( CONSTRAINT PK_TaxIds PRIMARY KEY (TaxId));
CREATE INDEX NI_TaxIdsStatus ON TaxIds ( NVL(Status,0) ) LOCAL;
Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100101, 111, NULL);
Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100102, 111, NULL);
Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100103, 111, NULL);
Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100104, 111, NULL);
Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (200101, 222, NULL);
Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (200102, 222, NULL);
Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (200103, 222, NULL);
--Session_1 return TAXID=100101
select TAXID from TAXIDS where LOCATIONID=111 and NVL(STATUS,0)=0 AND rownum=1 for update
--Session_2 waits commit
select TAXID from TAXIDS where LOCATIONID=111 and NVL(STATUS,0)=0 AND rownum=1 for update
--Session_1
update TAXIDS set STATUS=1 Where TaxId=100101;
commit;
--Session_2 return 100101 opps!?
--Session_1 return TAXID=100102
select TAXID, STATUS from TAXIDS where LOCATIONID=111 and NVL(STATUS,0)=0 AND rownum=1 for update
--Session_2 waits commit
select TAXID, STATUS from TAXIDS where LOCATIONID=111 and NVL(STATUS,0)=0 AND rownum=1 for update
--Session_1
update TAXIDS set STATUS=1 Where TaxId=100102;
commit;
--Session_2 return 100103

This is a bug. Got to be a bug.
This should be nothing to do with indeterminate results from ROWNUM, and nothing to do with read consistency at the point of statement start time in session2., surely.
Session 2 should never return 100101 once the lock from session 1 is released.
The SELECT FOR UPDATE should restart and 100101 should not be selected as it does not meet the criteria of the select.
A statement restart should ensure this.
A number of demos highlight this.
Firstly, recall the original observation in the original test case.
Setup
SQL> DROP TABLE taxids;
Table dropped.
SQL>
SQL> CREATE TABLE TaxIds
2 (TaxId NUMBER(6) NOT NULL,
3   LocationId NUMBER(3) NOT NULL,
4   Status NUMBER(1))
5 PARTITION BY LIST (LocationId)
6 (PARTITION P111 VALUES (111),
7   PARTITION P222 VALUES (222),
8   PARTITION P333 VALUES (333));
Table created.
SQL>
SQL> ALTER TABLE TaxIds ADD ( CONSTRAINT PK_TaxIds PRIMARY KEY (TaxId));
Table altered.
SQL>
SQL> CREATE INDEX NI_TaxIdsStatus ON TaxIds ( NVL(Status,0) ) LOCAL;
Index created.
SQL>
SQL>
SQL> Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100101, 111, NULL);
1 row created.
SQL> Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100102, 111, NULL);
1 row created.
SQL> Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100103, 111, NULL);
1 row created.
SQL> Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100104, 111, NULL);
1 row created.
SQL> Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (200101, 222, NULL);
1 row created.
SQL> Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (200102, 222, NULL);
1 row created.
SQL> commit;
Commit complete.
SQL> Original observation:
Session1>SELECT taxid
2 FROM   taxids
3 WHERE locationid    = 111
4 AND    NVL(STATUS,0) = 0
5 AND    ROWNUM        = 1
6 FOR UPDATE;
     TAXID
    100101
Session1>
--> Session 2 with same statement hangs until
Session1>BEGIN
2   UPDATE taxids SET status=1 WHERE taxid=100101;
3   COMMIT;
4 END;
5 /
PL/SQL procedure successfully completed.
Session1>
--> At which point, Session 2 returns
Session2>SELECT taxid
2 FROM   taxids
3 WHERE locationid    = 111
4 AND    NVL(STATUS,0) = 0
5 AND    ROWNUM        = 1
6 FOR UPDATE;
     TAXID
    100101
Session2>There's no way that session 2 should have returned 100101. That is the point of FOR UPDATE. It completely reintroduces the lost UPDATE scenario.
Secondly, what happens if we drop the index.
Let's reset the data and drop the index:
Session1>UPDATE taxids SET status=0 where taxid=100101;
1 row updated.
Session1>commit;
Commit complete.
Session1>drop index NI_TaxIdsStatus;
Index dropped.
Session1>Then try again:
Session1>SELECT taxid
2 FROM   taxids
3 WHERE locationid    = 111
4 AND    NVL(STATUS,0) = 0
5 AND    ROWNUM        = 1
6 FOR UPDATE;
     TAXID
    100101
Session1>
--> Session 2 hangs again until
Session1>BEGIN
2   UPDATE taxids SET status=1 WHERE taxid=100101;
3   COMMIT;
4 END;
5 /
PL/SQL procedure successfully completed.
Session1>
--> At which point in session 2:
Session2>SELECT taxid
2 FROM   taxids
3 WHERE locationid    = 111
4 AND    NVL(STATUS,0) = 0
5 AND    ROWNUM        = 1
6 FOR UPDATE;
     TAXID
    100102
Session2>Proves nothing, Non-deterministic ROWNUM you say.
Then let's reset, recreate the index and explicity ask then for row 100101.
It should give the same result as the ROWNUM query without any doubts over the ROWNUM, etc.
If the original behaviour was correct, session 2 should also be able to get 100101:
Session1>SELECT taxid
2 FROM   taxids
3 WHERE locationid    = 111
4 AND    NVL(STATUS,0) = 0
5 AND    taxid         = 100101
6 FOR UPDATE;
     TAXID
    100101
Session1>
--> same statement hangs in session 2 until
Session1>BEGIN
2   UPDATE taxids SET status=1 WHERE taxid=100101;
3   COMMIT;
4 END;
5 /
PL/SQL procedure successfully completed.
Session1>
--> so session 2 stops being blocked and:
Session2>SELECT taxid
2 FROM   taxids
3 WHERE locationid    = 111
4 AND    NVL(STATUS,0) = 0
5 AND    taxid         = 100101
6 FOR UPDATE;
no rows selected
Session2>Of course, this is how it should happen, surely?
Just to double check, let's reintroduce ROWNUM but force the order by to show it's not about read consistency at the start of the statement - restart should prevent it.
(reset, then)
Session1> select t.taxid
2   from
3    (select taxid, rowid rd
4      from   taxids
5      where locationid = 111
6      and    nvl(status,0) = 0
7      order by taxid) x
8   , taxids t
9   where t.rowid = x.rd
10   and   rownum = 1
11   for update of t.status;
     TAXID
    100101
Session1>
--> Yes, session 2 hangs until...
Session1>BEGIN
2   UPDATE taxids SET status=1 WHERE taxid=100101;
3   COMMIT;
4 END;
5 /
PL/SQL procedure successfully completed.
Session1>
--> and then
Session2> select t.taxid
2   from
3    (select taxid, rowid rd
4      from   taxids
5      where locationid = 111
6      and    nvl(status,0) = 0
7      order by taxid) x
8   , taxids t
9   where t.rowid = x.rd
10   and   rownum = 1
11   for update of t.status;
     TAXID
    100102
Session2>Session 2 should never be allowed to get 100101 once the lock is released.
This is a bug.
The worrying thing is that I can reproduce in 9.2.0.8 and 11.2.0.2.

Wrong results from "Select count(*) from tbl"

I am the user of an Oracle DB and I am getting what
look like wrong counts using "Select count(*)" statments.
It first occurred when I tried to get monthly record counts with
Select count(*), month
from tbl
group by month
(Note this is the query I used with the exception
of a change in the table name. The month field is numeric)
All the monthly counts but one looked like it was 2x what it should be.
Oddly enough if I tried
Select count(*), month
from tbl
where month = 200302
group by month
OR
Select count(*), month
from tbl
where month in (200301 200302)
group by month
I got what looked correct.
I even got the 2X problem when I asked for a count on
the entire table using
Select count(*)
from tbl
One of our DBAs suggested the problem has somehting to do with
the indexes and not running analyze on the table recently.
I'll note also that the table is partitioned.
I think it's Oracle version 8.1.7.4.0 running on a Sun box.
Has anyone seen this before or does anyone have any
suggestions on the cause of the problem?
I have been told it has to do with indexes
and I know there are many indexes on this table.
The table is also partitioned.
Thanks,
- john

plz copy and paste here your tests
i am running 8.1.7.4.0 too and all is fine here...
(i heard about a count(*) problem but on a lite version of an old 8.0.x...)
Fred

Crystal XI R2 giving wrong result from a query...

I created a very simple query using 3 conditions with OR operator, looking for 3 columns within a date range. CR returns the results only for the first condition and ignores the 2 other conditions. I ran exactly the same query using the syntax from CR SQL in MS SQL Management Studio and it works fine there.
Here is the Record Selection syntax
{CONTACT2.UBATSENDDT} = {?Date} OR
{CONTACT2.UBWTSENDDT} = {?Date} OR
{CONTACT2.UBPTSENDDT} = {?Date}
Has anyone else experienced it too? Is there a trick to fix it? Please HELP....

Thanks Jamie. That solved the problem. I've been using it for so long never knew about this setting. That's what happens when you learn things on your own. Appreciate your quick and right on the money response. Are there any other Report Options setting that should be turned on as a precaution?
Thanks Naga for suggestion but that wasn't the issue. I had already almost everything else.
Edited by: ManojT on Mar 2, 2012 8:51 AM

Bug 2679062 - Wrong results possible from multi-column INLIST - though stat

Hi,
The following test case is supplied in the metalink in bug no. 2871341, the base bug for this bug is 2679062.
REPRODUCIBILITY:
Reproduces constantly with simple test case below:
TEST CASE:
DROP TABLE A1
CREATE TABLE A1 (X1 VARCHAR2(10), X2 VARCHAR2(10))
REM *********** Create the second table: ***************
DROP TABLE A2
CREATE TABLE A2 (X1 VARCHAR2(10), X2 VARCHAR2(10))
INSERT INTO A1 VALUES ('1','2');
INSERT INTO A2 VALUES ('3','4');
COMMIT;
CREATE INDEX A1_X1 ON A1(X1 );
CREATE INDEX A1_X2 ON A1(X2);
CREATE INDEX A2_X1 ON A2(X1);
CREATE INDEX A2_X2 ON A2(X2);
CREATE OR REPLACE VIEW A_ALL AS SELECT * FROM A1 UNION ALL SELECT * FROM A2;
ANALYZE TABLE A1 COMPUTE STATISTICS;
ANALYZE TABLE A2 COMPUTE STATISTICS;
SELECT * FROM A_ALL;
SELECT * FROM A_ALL WHERE (X1='1' AND X2='2') ;
SELECT * FROM A_ALL WHERE ((X1='1' AND X2='2') OR (X1='3' AND X2='4'));
The 2nd query returns answer while the second is not !
The following is published in the 9.2.0.4 fixed bug list:
" 9204 - 2679062 - Wrong results possible from multi-column INLIST "
I have installed 9.2.0.4 patch set on a win 2000 machine Oracle and saw that the above case is actually solved but our application which has a very similar case doesn't.
After investigating I found the following test case that fails, it reproduces only when you have index on all columns (covering index):
drop table t1_1;
drop table t1_2;
create table t1_1(c1 number, c2 number, c3 number);
create table t1_2(c1 number, c2 number, c3 number);
create index t1_1_ix on t1_1(c1, c2, c3);
create index t1_2_ix on t1_2(c1, c2, c3);
create or replace view t1 as select * from t1_1 union all select * from t1_2;
insert into t1_1 values(1, 2, 100);
insert into t1_2 values(1, 2, 200);
commit;
analyze table t1_1 compute statistics;
analyze table t1_2 compute statistics;
prompt
prompt #######################################
prompt try 1 - works fine
prompt #######################################
prompt
select * from t1
where
(c1=1)
and
( (c2=2) and (c3=100)
prompt
prompt #######################################
prompt try 2 - works fine
prompt #######################################
prompt
select * from t1
where
(c1=1)
and
(c2=2) and (c3=200)
prompt
prompt #######################################
prompt try 3 - try 1 OR try 2 does not work !
prompt #######################################
prompt
select * from t1
where
(c1=1)
and
( ( (c2=2) and (c3=100) )
or
( (c2=2) and (c3=200) )
opened a TAR and wanted to share with you.
Tal Olier ([email protected]).

Hi,
The following test case is supplied in the metalink in bug no. 2871341, the base bug for this bug is 2679062.
REPRODUCIBILITY:
Reproduces constantly with simple test case below:
TEST CASE:
DROP TABLE A1
CREATE TABLE A1 (X1 VARCHAR2(10), X2 VARCHAR2(10))
REM *********** Create the second table: ***************
DROP TABLE A2
CREATE TABLE A2 (X1 VARCHAR2(10), X2 VARCHAR2(10))
INSERT INTO A1 VALUES ('1','2');
INSERT INTO A2 VALUES ('3','4');
COMMIT;
CREATE INDEX A1_X1 ON A1(X1 );
CREATE INDEX A1_X2 ON A1(X2);
CREATE INDEX A2_X1 ON A2(X1);
CREATE INDEX A2_X2 ON A2(X2);
CREATE OR REPLACE VIEW A_ALL AS SELECT * FROM A1 UNION ALL SELECT * FROM A2;
ANALYZE TABLE A1 COMPUTE STATISTICS;
ANALYZE TABLE A2 COMPUTE STATISTICS;
SELECT * FROM A_ALL;
SELECT * FROM A_ALL WHERE (X1='1' AND X2='2') ;
SELECT * FROM A_ALL WHERE ((X1='1' AND X2='2') OR (X1='3' AND X2='4'));
The 2nd query returns answer while the second is not !
The following is published in the 9.2.0.4 fixed bug list:
" 9204 - 2679062 - Wrong results possible from multi-column INLIST "
I have installed 9.2.0.4 patch set on a win 2000 machine Oracle and saw that the above case is actually solved but our application which has a very similar case doesn't.
After investigating I found the following test case that fails, it reproduces only when you have index on all columns (covering index):
drop table t1_1;
drop table t1_2;
create table t1_1(c1 number, c2 number, c3 number);
create table t1_2(c1 number, c2 number, c3 number);
create index t1_1_ix on t1_1(c1, c2, c3);
create index t1_2_ix on t1_2(c1, c2, c3);
create or replace view t1 as select * from t1_1 union all select * from t1_2;
insert into t1_1 values(1, 2, 100);
insert into t1_2 values(1, 2, 200);
commit;
analyze table t1_1 compute statistics;
analyze table t1_2 compute statistics;
prompt
prompt #######################################
prompt try 1 - works fine
prompt #######################################
prompt
select * from t1
where
(c1=1)
and
( (c2=2) and (c3=100)
prompt
prompt #######################################
prompt try 2 - works fine
prompt #######################################
prompt
select * from t1
where
(c1=1)
and
(c2=2) and (c3=200)
prompt
prompt #######################################
prompt try 3 - try 1 OR try 2 does not work !
prompt #######################################
prompt
select * from t1
where
(c1=1)
and
( ( (c2=2) and (c3=100) )
or
( (c2=2) and (c3=200) )
opened a TAR and wanted to share with you.
Tal Olier ([email protected]).

Wrong results for context search on empty element tags

I'm using Oracle DBMS 11.1 and 11.2 and created a context index on an XML column (section group: PATH_SECTION_GROUP).
When entering a query like
SELECT count(*) FROM my_table t WHERE contains (t.co_xml,'hasPath(/tag1/tag2)') > 0
I get wrong results if tag2 is an empty element tag (<tag2/>) that appears somewhere within the
XML instance, but NOT directly under tag1.
E.g., the following XML instance is found (but shouldn't!):
<a>
<tag1>bla<tag3>bla</tag3></tag1>
<tag4>bla<tag2/></tag4>
</a>
This seems to happen only for empty element tags. Is this a known bug and does anybody know a workaround?
Thanks in advance for your help!
Roman

I am unable to reproduce the problem. Can you provide a copy and paste of an actual run, including create table, insert data, create index, and select, as I have done below?
SCOTT@orcl_11g> select * from v$version
2 /
BANNER
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
PL/SQL Release 11.1.0.6.0 - Production
CORE 11.1.0.6.0 Production
TNS for 32-bit Windows: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production
SCOTT@orcl_11g> create table my_table
2 (co_xml xmltype)
3 /
Table created.
SCOTT@orcl_11g> insert into my_table values (
2 xmltype ('<?xml version="1.0"?>
3 <tag5>
4 <tag1>bla<tag3>bla</tag3></tag1>
5 <tag4>bla<tag2/></tag4>
6 </tag5>'))
7 /
1 row created.
SCOTT@orcl_11g> create index my_idx
2 on my_table (co_xml)
3 indextype is ctxsys.context
4 parameters ('section group ctxsys.path_section_group')
5 /
Index created.
SCOTT@orcl_11g> SELECT count(*)
2 FROM my_table t
3 WHERE contains (t.co_xml, 'hasPath (//tag1/tag2)') > 0
4 /
COUNT(*)
 0
SCOTT@orcl_11g> SELECT count(*)
2 FROM my_table t
3 WHERE contains (t.co_xml, 'hasPath (//tag1/tag3)') > 0
4 /
COUNT(*)
 1
SCOTT@orcl_11g>

Query giving wrong results

Below is the query thats giving me wrong results ...can anyone help me figure where i am going wrong :(
SQL> select count(*) from t where source='LP1.1';
COUNT(*)
        69
SQL> select count(*) from tblspring where line_a='LP1.1';
COUNT(*)
       233now when i join these two table ...the total counts exceeds the expected records that i want
SQL> select count(*) from t , tblspring where t.source=tblspring.line_a and t.source='LP1.1';
COUNT(*)
     16077

the thing is i want to filter only those records from table t where the column named - source is equal to the column named line_a from table tblspring from the query in table t i get 69 records ....
now when i match the it table tblspring with the condition
i want the number of records should be less than or equal to 69 but not more than 69
Edited by: Suhail Faraaz on Mar 5, 2011 7:31 AM

[HELP] AGO function return wrong result

Hi, i try to implement ago function in OBIEE, but the result is not as expected. Please help me to configure Time Dimension to get this work.
My case:
- I have a time dimension with this configuration:
[http://i264.photobucket.com/albums/ii176/necrombi/NEO/1-1.png]
Time Hierarchy: Total > Year > Quarter > Month > Day
Year:
Primary key: Calendar_year_cal_year_code
Chronological key: Does not define
Quarter:
Primary key: Calendar_quarter_description
Chronological key: Does not define
Month:
Primary key: Calendar_month_description
Chronological key: Calendar_month_description
Day:
Primary key: Dimension_key
Chronological key: Day_day_code
My ago function: AGO(expression, mywh.D_qn_thoigianDim."month", 1)
I do not understand why i get this wrong results:
[http://i264.photobucket.com/albums/ii176/necrombi/NEO/2.png]
Does anyone know how to solve this?
Edited by: 864451 on Jun 8, 2011 5:11 AM

Hi, thanks for your reply.
I implemented Time dimension with your recommend, and have time dimension like this:
Time Hierarchy: Total > Year > Quarter > Month > Day
Year:
Primary key: Calendar_year_start_date
Chronological key: Calendar_year_start_date
Quarter:
Primary key: Calendar_quarter_start_date
Chronological key: Calendar_quarter_start_date
Month:
Primary key: Calendar_month_start_date
Chronological key: Calendar_month_start_date
Day:
Primary key: Day
Chronological key: Dimension_key
And Ago function works fine with month level: AGO(expression, mywh.D_qn_thoigianDim."month", n)
But return sum result of 12 month with: AGO(expression, mywh.D_qn_thoigianDim."year", 1)
In my case, i just use AGO(expression, mywh.D_qn_thoigianDim."month", 12) to get year ago value. But i still don't understand clearly about OBIEE Time Serries functions.
Thanks,
Dung Nguyen

Pathfinder produces very wrong results. Long time Illy user. **URGENT**

Running Mac 10.10.1 (newest Yosemite)
Adobe CC
PROBLEM #1
Recently when performing a simple "minus front" with two objects, I get very wrong results. See image below. I created icons that are knocking out the BG behind it. Had no problems with the others until I got to the fork. I created the fork using rectangles, and the new direct select to create round corners feature. I can work around this problem by creating an opacity mask on the BG and pasting in the icon at full black. However, when I import that into inDesign, the fork still shows as it's original color. Ok fine. I can export from AI as a .png and avoid it. But that's a pain, and CC has already been pushing my buttons this week. And I'd rather just figure out the why.
I also rasterized the fork icon in AI, then performed an image trace to vectorize it again - in hopes that this would be a magical fix. It was not. It ended up being a worse result than before, after using minus front.
PROBLEM #2
I found that if I alt-drag these elements, and then perform the minus front, I get very close to what is expected. However, this is where it gets really weird. Once I drag the newly created shape around my artboard, the area that had the minus front performed on it, begins to change. See the pictures below picture one for reference. What the eff. This is really confusing.
Any help would be great. I am putting together a branding guidelines tonight for my client and this happens to be one of those little snags.
Thanks
Problem 1 picture - left side is after minus front
Problem 2 pictures - after minus front, and moved around a few times

You've got the Align-to-Pixel Grid turned on and are not using whole pixels for your objects.

Please Help Urgent:Fast Search returning wrong result sets

Hi All,
We are facing below issue with fast search.
Currently in My project when we are searching for a phrase it is returning wrong result sets.
For example if we search for “Endura”, It is returning documents related to
Endura as well as Centura.
But the expected results are only Endura documents.
When we look in to the documents we didn’t find the search term (“Endura” ) either inside document content or in its meta data.
In order to resolve the issue we tried the below steps
1-
We manually edited and saved the document, to ensure the appropriate Guid association to metadata.
2-
Index reset
3-
Full crawl
But no luck so far.
Please help.Thanks in advance.
Regards
Subrat

Subrat,
This may be related to spellchecking or may be synonym. Spellcheck is based on indexed terms.
The best test would be to run the queries from qrserver (13280) and then look at the spellcheck query transformations. If spellchecking is not doing it, then you must have a synonym setup .Check your keyword/synonyms from the SharePoint side.

0CRM_OPPT_H (Transaction RSA3 gives wrong result)

Hi gurus,
0CRM_OPPT_H (Transaction RSA3 gives wrong result)
BBPCRM 4.0
BW 3.50 version
I had enhanced the structure "crmt_bw_oppt_h"
and also written a BADI to populate Opportunity header status.
But when I run extract checker RSA3 for CRM data,
I get wrong number of records.
I am having 95 records for Opportunities header data.
Data Records / Call = "100"
Display Extr. Calls = "10"
Above settings, I am retrieving only 61 records.
Data Records / Call = "1"
Display Extr. Calls = "200"
For the above settings in RSA3,
I am able to retrieve 95 records correctly.
The problem is that in RSA1 transaction of BW 3.50 server also,
61 records are being loaded from CRM server.
Could this be a Cache memory problem,
Are any of my BASIS settings a cause for this problem?
Any help is really appreciated and will be rewarded.
Thanks,
Aby Jacob
========

Dear Friends,
I had to do a small correction in my BADI code.
I got a solution from Online SAP HELP portal.
http://help.sap.com/saphelp_nw04/helpdata/en/eb/3e7cf4940e11d295df0000e82de14a/frameset.htm
Notes on BADI Usage
====================
The instance generated through the factory method should be declared
as globally as possible or generally be passed as a parameter
to ensure that the initialization process must be run as rarely as possible
just once would be best. In no case should you discard the instance as soon as
it is generated or repeatedly run the initialization process in a loop.
Within the adapter class interface,
required database accesses are buffered locally,
so that each access is executed once only.
However, repeated initialization makes
the buffer useless and dramatically reduces performance.
Due to the local buffering, you can call Business-Add-In methods
without having to expect considerable performance restrictions,
even if no active implementations exist.
Also, if the definition of the Business-Add-In is filter-dependent,
a single instance is sufficient.
However, you should not do without initialization altogether.
Even if you could call static methods of the implementing
class of the Business-Add-In implementation without an instance,
you would lose the benefit of performance improvement through
the Business-Add-Ins and the possibility of multiple use.
If you switch the method type in the interface from the static method
to the instance method at any time in the future,
many code adjustments are required.
In addition, you can no longer use default code that is provided.
Many Thanks to ROBIN
and the whole SDN team
Aby Jacob ,,,,,

List.removeAll(otherList) - wrong result

Hi guys,
I have 2 Lists:
1.     carList
2.     documentList
*both contain the same type: car PLUS I have overloaded the hashCode and equals of car
carList has 1106 items
documentList has 88 items
I would like to remove the 88 items of documentList from the carList.
(simple math: 1106-88=1018)
By doing this:
(1)
this.carList.removeAll(documentList);
the carList.size() = 1013 (?!?!)by doing this:
(2)
             for (int x=carList.size()-1; x>=0; x--)
                  Car cx = (Car) carList.get(x);
                  for (int i=documentList.size()-1; i>=0; i--)
                       Car ci = (Car) documentList.get(i);
                       if (cx.equals(ci))
                            carList.remove(x);
                            documentList.remove(i);
                            break;
             }I get 1018 (correct)
Question: Why am I getting the wrong result in option 1? (once again, I have overloaded the hashCode and equals of car)

I am going to guess - and it is a guess - that it is down to the way the removeAll() method works 'under the covers' so to speak. Like you, I cannot think of any reason why the results should differ given that I would expect the equals() method - which you overrode - that would be called upon most. Sorry I cannot help any further.

Filter results from Multi Entity Search/Global Search

Hi,
Could it be possible to filter results from MS CRM 2015 Multi entity search (global search) similar to RetrieveMultiple message plugin.
Thanks

Possibly, this could be BUG.
Haven't experience this kind of issue...
Cheers,
Gulab Prasad
Technology Consultant
My Blog:
Exchange Ranger
Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

Why does Lookout receive wrong count from FP-CTR-500

Counter module flashes light count = to field pulse input device. Lookout fieldpoint object follows device count, but occassionally double counts giving wrong results. Is this a hardware problem with the counter module? A second counter in the system works as expected. Both are wired the same way and read the same way in the software and are receiving signals from like field devices.

Mike,
To rule out the possibility of this being a hardware problem in the FP-CTR-500 module, you can swap both of your FP-CTR-500 modules. I suspect that the problem will remain on the same signal/channel indicating that it is most likely a signal problem.
You may be receiving a double count as a result of noise or signal differences in the sensors wired to the various channels. To reduce the likelihood of a spurious signal causing a double count, you can enable the low pass filter on the FP-CTR-500 to reject signals above 200 Hz. If you look at the signal on a scope, you may see that it is fairly noisy and could use some filtering. Also, consider if one sensor has a longer cable run then the other or if it routes near something that may be electricall
y noisy.
Regards,
Aaron

Wrong results after upgrading 10g database to 11.2.0.2.6

Hi,
Do anyone know, why the following query results are different?
Not Working query:
sql1:
select col1 from tab1
where col1 = (select '123' from dual)
Working query:
sql2:
select col1 from tab1
where col1 = '123';
Both the sql1 and sql2 are returning same reseults in 10g database , but not in 11g.

Pl post OS details along with sample outputs and explain plans from the the sql1 statement from the two databases. These MOS Docs may help also
Things to Consider Before Upgrading to 11.2.0.2 to Avoid Poor Performance or Wrong Results [ID 1320966.1]
Wrong Results on 11.2.0.2 with Function-Based Index and OR Expansion [ID 1264550.1]
Wrong Results/No Rows for Sql Involving Functions in 11.2.0.2. [ID 1380679.1]
HTH
Srini

Expected (wrong?) results from Express VI - a bug?

Similar Messages

Maybe you are looking for