PDF error after applying SP1

After applying SP1 i got following error during export to PDF
Export Error:
"Index and lenght must refer to a location within a string.
Parameter name: lenght"Workaround solution with following post:
"SP1 - Exception of type
Microsoft.ReportingServices.ReportRendering.ReportRenderingException was
thrown" by Rahul
U¿ytkownik "kamel" <ddd@.ddd.com> napisa³ w wiadomo¶ci
news:e9gFBIQXEHA.3016@.tk2msftngp13.phx.gbl...
> After applying SP1 i got following error during export to PDF
> Export Error:
> "Index and lenght must refer to a location within a string.
> Parameter name: lenght"
>|||I have a straight forward workaround: Always use a Lang-Country code pair.
For example, in report designer, the language options for Norwegian are
Name Lang-County Code
* Norwegian no
* Norwegian (Bokmal) nb-NO
* Norwegian (Nynorsk) nn-NO
To avoid the error when exporting to PDF always use nb-NO or nn-NO.
--
Bruce Johnson [MSFT]
Microsoft SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"kamel" <ddd@.ddd.com> wrote in message
news:e1TnW%23cXEHA.2364@.TK2MSFTNGP12.phx.gbl...
> Workaround solution with following post:
> "SP1 - Exception of type
> Microsoft.ReportingServices.ReportRendering.ReportRenderingException was
> thrown" by Rahul
> U¿ytkownik "kamel" <ddd@.ddd.com> napisa³ w wiadomo¶ci
> news:e9gFBIQXEHA.3016@.tk2msftngp13.phx.gbl...
> > After applying SP1 i got following error during export to PDF
> >
> > Export Error:
> > "Index and lenght must refer to a location within a string.
> > Parameter name: lenght"
> >
> >
>

pb with a trigger

hello,
I've a problem with a trigger :
this trigger update a file with an index field but it's return an error
: UPDATE stop because the Set option : "QUOTED_IDENTIFIER" return bad
parameters
for information, this is my trigger :
CREATE TRIGGER COOP_article ON F_ARTICLE FOR insert AS
SET NOCOUNT ON
set arithabort on
set concat_null_yields_null on
set quoted_identifier on
set ansi_nulls on
set ansi_padding on
set ansi_warnings on
set numeric_roundabort off
declare @.code varchar(17)
select @.code=ar_ref from inserted
begin
*/ replace if reference = 0 */
if @.code='0'
begin
update f_article set ar_ref='test' from f_article join
inserted on f_article.cbmarq=inserted.cbmarq
end
end
if you ave an idea...
thanks
philnedPerhaps the trigger was created with SET QUOTED_IDENTIFIER OFF. This
setting is remembered for subsequent trigger executions. Try:
SET QUOTED_IDENTIFIER ON
SET ANSI_NULLS ON
GO
CREATE TRIGGER COOP_article ON F_ARTICLE FOR insert AS
SET NOCOUNT ON
set arithabort on
set concat_null_yields_null on
set quoted_identifier on
set ansi_nulls on
set ansi_padding on
set ansi_warnings on
set numeric_roundabort off
declare @.code varchar(17)
select @.code=ar_ref from inserted
begin
*/ replace if reference = 0 */
if @.code='0'
begin
update f_article set ar_ref='test' from f_article join
inserted on f_article.cbmarq=inserted.cbmarq
end
end
GO
Hope this helps.
Dan Guzman
SQL Server MVP
"philned" <philned@.wanadoo.fr> wrote in message
news:418783e6$0$9305$636a15ce@.news.free.fr...
> hello,
> I've a problem with a trigger :
> this trigger update a file with an index field but it's return an error :
> UPDATE stop because the Set option : "QUOTED_IDENTIFIER" return bad
> parameters
> for information, this is my trigger :
> CREATE TRIGGER COOP_article ON F_ARTICLE FOR insert AS
> SET NOCOUNT ON
> set arithabort on
> set concat_null_yields_null on
> set quoted_identifier on
> set ansi_nulls on
> set ansi_padding on
> set ansi_warnings on
> set numeric_roundabort off
> declare @.code varchar(17)
> select @.code=ar_ref from inserted
> begin
> */ replace if reference = 0 */
> if @.code='0'
> begin
> update f_article set ar_ref='test' from f_article join
> inserted on f_article.cbmarq=inserted.cbmarq
> end
> end
>
> if you ave an idea...
> thanks
> philnedsql

pb with a trigger

hello,
I've a problem with a trigger :
this trigger update a file with an index field but it's return an error
: UPDATE stop because the Set option : "QUOTED_IDENTIFIER" return bad
parameters
for information, this is my trigger :
CREATE TRIGGER COOP_article ON F_ARTICLE FOR insert AS
SET NOCOUNT ON
set arithabort on
set concat_null_yields_null on
set quoted_identifier on
set ansi_nulls on
set ansi_padding on
set ansi_warnings on
set numeric_roundabort off
declare @.code varchar(17)
select @.code=ar_ref from inserted
begin
*/ replace if reference = 0 */
if @.code='0'
begin
update f_article set ar_ref='test' from f_article join
inserted on f_article.cbmarq=inserted.cbmarq
end
end
if you ave an idea...
thanks
philnedPerhaps the trigger was created with SET QUOTED_IDENTIFIER OFF. This
setting is remembered for subsequent trigger executions. Try:
SET QUOTED_IDENTIFIER ON
SET ANSI_NULLS ON
GO
CREATE TRIGGER COOP_article ON F_ARTICLE FOR insert AS
SET NOCOUNT ON
set arithabort on
set concat_null_yields_null on
set quoted_identifier on
set ansi_nulls on
set ansi_padding on
set ansi_warnings on
set numeric_roundabort off
declare @.code varchar(17)
select @.code=ar_ref from inserted
begin
*/ replace if reference = 0 */
if @.code='0'
begin
update f_article set ar_ref='test' from f_article join
inserted on f_article.cbmarq=inserted.cbmarq
end
end
GO
Hope this helps.
Dan Guzman
SQL Server MVP
"philned" <philned@.wanadoo.fr> wrote in message
news:418783e6$0$9305$636a15ce@.news.free.fr...
> hello,
> I've a problem with a trigger :
> this trigger update a file with an index field but it's return an error :
> UPDATE stop because the Set option : "QUOTED_IDENTIFIER" return bad
> parameters
> for information, this is my trigger :
> CREATE TRIGGER COOP_article ON F_ARTICLE FOR insert AS
> SET NOCOUNT ON
> set arithabort on
> set concat_null_yields_null on
> set quoted_identifier on
> set ansi_nulls on
> set ansi_padding on
> set ansi_warnings on
> set numeric_roundabort off
> declare @.code varchar(17)
> select @.code=ar_ref from inserted
> begin
> */ replace if reference = 0 */
> if @.code='0'
> begin
> update f_article set ar_ref='test' from f_article join
> inserted on f_article.cbmarq=inserted.cbmarq
> end
> end
>
> if you ave an idea...
> thanks
> philned

pb with a trigger

hello,
I've a problem with a trigger :
this trigger update a file with an index field but it's return an error
: UPDATE stop because the Set option : "QUOTED_IDENTIFIER" return bad
parameters
for information, this is my trigger :
CREATE TRIGGER COOP_article ON F_ARTICLE FOR insert AS
SET NOCOUNT ON
set arithabort on
set concat_null_yields_null on
set quoted_identifier on
set ansi_nulls on
set ansi_padding on
set ansi_warnings on
set numeric_roundabort off
declare @.code varchar(17)
select @.code=ar_ref from inserted
begin
*/ replace if reference = 0 */
if @.code='0'
begin
update f_article set ar_ref='test' from f_article join
inserted on f_article.cbmarq=inserted.cbmarq
end
end
if you ave an idea...
thanks
philned
Perhaps the trigger was created with SET QUOTED_IDENTIFIER OFF. This
setting is remembered for subsequent trigger executions. Try:
SET QUOTED_IDENTIFIER ON
SET ANSI_NULLS ON
GO
CREATE TRIGGER COOP_article ON F_ARTICLE FOR insert AS
SET NOCOUNT ON
set arithabort on
set concat_null_yields_null on
set quoted_identifier on
set ansi_nulls on
set ansi_padding on
set ansi_warnings on
set numeric_roundabort off
declare @.code varchar(17)
select @.code=ar_ref from inserted
begin
*/ replace if reference = 0 */
if @.code='0'
begin
update f_article set ar_ref='test' from f_article join
inserted on f_article.cbmarq=inserted.cbmarq
end
end
GO
Hope this helps.
Dan Guzman
SQL Server MVP
"philned" <philned@.wanadoo.fr> wrote in message
news:418783e6$0$9305$636a15ce@.news.free.fr...
> hello,
> I've a problem with a trigger :
> this trigger update a file with an index field but it's return an error :
> UPDATE stop because the Set option : "QUOTED_IDENTIFIER" return bad
> parameters
> for information, this is my trigger :
> CREATE TRIGGER COOP_article ON F_ARTICLE FOR insert AS
> SET NOCOUNT ON
> set arithabort on
> set concat_null_yields_null on
> set quoted_identifier on
> set ansi_nulls on
> set ansi_padding on
> set ansi_warnings on
> set numeric_roundabort off
> declare @.code varchar(17)
> select @.code=ar_ref from inserted
> begin
> */ replace if reference = 0 */
> if @.code='0'
> begin
> update f_article set ar_ref='test' from f_article join
> inserted on f_article.cbmarq=inserted.cbmarq
> end
> end
>
> if you ave an idea...
> thanks
> philned

pb with a trigger

hello,

I've a problem with a trigger :
this trigger update a file with an index field but it's return an error
: UPDATE stop because the Set option : "QUOTED_IDENTIFIER" return bad
parameters

for information, this is my trigger :

CREATE TRIGGER COOP_article ON F_ARTICLE FOR insert AS
SET NOCOUNT ON
set arithabort on
set concat_null_yields_null on
set quoted_identifier on
set ansi_nulls on
set ansi_padding on
set ansi_warnings on
set numeric_roundabort off
declare @.code varchar(17)
select @.code=ar_ref from inserted
begin
*/ replace if reference = 0 */
if @.code='0'
begin

update f_article set ar_ref='test' from f_article join
inserted on f_article.cbmarq=inserted.cbmarq
end
end

if you ave an idea...
thanks
philned[posted and mailed, please reply in news]

philned (philned@.wanadoo.fr) writes:
> I've a problem with a trigger :
> this trigger update a file with an index field but it's return an error
>: UPDATE stop because the Set option : "QUOTED_IDENTIFIER" return bad
> parameters

This is because there is an indexed view or an indexed computed
column some where.

Putting all those SET commands in the trigger is not a good idea, because
it may cause recompilations which can be expensive performancewise.

Instead make sure that you issue a SET ARITHABORT ON when you connect.
You can also set this default for your database, or even your setver.

As for QUOTED_IDENTIFIER, this setting is a bit special. It doesn't
help if you set it in the trigger, because it is the setting of
QUOTED_IDENTIFER when the trigger was created that applies. This also
applies to the setting ANSI_NULLS.

There are some tools that unfortunately turn of QUOTED_IDENTIFIER by
default. The command-line tool OSQL is one of them. Use -I with OSQL
to have QUOTED_IDENTIFIER on. The other is Enterprise Manger, but you
should not use EM for editing SQL Code, use Query Analyzer instead.

In short: you need to reload the trigger with QUOTED_IDENTIIER on.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

pb with "QUOTED_IDENTIFIER"

hello,
I've a problem with a trigger :
this trigger update a file with an index field but it's return an error
: UPDATE stop because the Set option : "QUOTED_IDENTIFIER" return bad
parameters
for information, this is my trigger :
CREATE TRIGGER COOP_article ON F_ARTICLE FOR insert AS
SET NOCOUNT ON
set arithabort on
set concat_null_yields_null on
set quoted_identifier on
set ansi_nulls on
set ansi_padding on
set ansi_warnings on
set numeric_roundabort off
declare @.code varchar(17)
select @.code=ar_ref from inserted
begin
*/ replace if reference = 0 */
if @.code='0'
begin
update f_article set ar_ref='test' from f_article join
inserted on f_article.cbmarq=inserted.cbmarq
end
end
if you ave an idea...
thanks
philned
Why are you setting quoted identifiers on? You don't seem to need it.
Same goes for most of the set statements.
"philned" wrote:

> hello,
> I've a problem with a trigger :
> this trigger update a file with an index field but it's return an error
> : UPDATE stop because the Set option : "QUOTED_IDENTIFIER" return bad
> parameters
> for information, this is my trigger :
> CREATE TRIGGER COOP_article ON F_ARTICLE FOR insert AS
> SET NOCOUNT ON
> set arithabort on
> set concat_null_yields_null on
> set quoted_identifier on
> set ansi_nulls on
> set ansi_padding on
> set ansi_warnings on
> set numeric_roundabort off
> declare @.code varchar(17)
> select @.code=ar_ref from inserted
> begin
> */ replace if reference = 0 */
> if @.code='0'
> begin
> update f_article set ar_ref='test' from f_article join
> inserted on f_article.cbmarq=inserted.cbmarq
> end
> end
>
> if you ave an idea...
> thanks
> philned
>

Pb table scan

I have a query like this :
select * from table
where champs1=val1 and champs2 =val2
I have an index on (champs1,champs2).
The table has 698694 rows.
The table scan cost 17770 i/os.
If the number of rows selected is greater than 4700, the optimizer choice
the table scan. If i force the index, i have 4762 i/os ( is less than
17770 )
I don't know why the optimizer choice the table scan ( is there a traceon,
command like the dbcc traceon(302) in sybase, that help you to understand
the choice of the optimizer ? ).
Thanks and sorry for my poor english.Have you tried clustering your index?
"ljbx" <pierre.lejoubioux@.nospam_atosorigin.com> wrote in message
news:1084801423.162182@.atn04...
> I have a query like this :
> select * from table
> where champs1=val1 and champs2 =val2
> I have an index on (champs1,champs2).
> The table has 698694 rows.
> The table scan cost 17770 i/os.
> If the number of rows selected is greater than 4700, the optimizer choice
> the table scan. If i force the index, i have 4762 i/os ( is less than
> 17770 )
> I don't know why the optimizer choice the table scan ( is there a traceon,
> command like the dbcc traceon(302) in sybase, that help you to understand
> the choice of the optimizer ? ).
> Thanks and sorry for my poor english.
>
>
>|||Execute this from Query Analyzer and look at the query plan. It will show
you the details... Then force the index you think is best and execute again,
compare the two.
You might try to update statistics on the table,
or drop /recreate the indices on the table and try again.
Generally however if a query returns more than 3-10% of the rows in the
table, the optimizer will choose a table scan.
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"ljbx" <pierre.lejoubioux@.nospam_atosorigin.com> wrote in message
news:1084801423.162182@.atn04...
> I have a query like this :
> select * from table
> where champs1=val1 and champs2 =val2
> I have an index on (champs1,champs2).
> The table has 698694 rows.
> The table scan cost 17770 i/os.
> If the number of rows selected is greater than 4700, the optimizer choice
> the table scan. If i force the index, i have 4762 i/os ( is less than
> 17770 )
> I don't know why the optimizer choice the table scan ( is there a traceon,
> command like the dbcc traceon(302) in sybase, that help you to understand
> the choice of the optimizer ? ).
> Thanks and sorry for my poor english.
>
>
>|||One possible reason is outdated statistics. Did you try UPDATE STATISTICS?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"ljbx" <pierre.lejoubioux@.nospam_atosorigin.com> wrote in message news:1084801423.162182@.atn
04...
> I have a query like this :
> select * from table
> where champs1=val1 and champs2 =val2
> I have an index on (champs1,champs2).
> The table has 698694 rows.
> The table scan cost 17770 i/os.
> If the number of rows selected is greater than 4700, the optimizer choice
> the table scan. If i force the index, i have 4762 i/os ( is less than
> 17770 )
> I don't know why the optimizer choice the table scan ( is there a traceon,
> command like the dbcc traceon(302) in sybase, that help you to understand
> the choice of the optimizer ? ).
> Thanks and sorry for my poor english.
>
>
>|||there is a primary key but not on this rows
"Adam Machanic" <amachanic@.air-worldwide.nospamallowed.com> a crit dans le
message de news:OIe9eACPEHA.3020@.tk2msftngp13.phx.gbl...
> Have you tried clustering your index?
> "ljbx" <pierre.lejoubioux@.nospam_atosorigin.com> wrote in message
> news:1084801423.162182@.atn04...
choice[vbcol=seagreen]
traceon,[vbcol=seagreen]
understand[vbcol=seagreen]
>

Pb table scan

I have a query like this :
select * from table
where champs1=val1 and champs2 =val2
I have an index on (champs1,champs2).
The table has 698694 rows.
The table scan cost 17770 i/os.
If the number of rows selected is greater than 4700, the optimizer choice
the table scan. If i force the index, i have 4762 i/os ( is less than
17770 )
I don't know why the optimizer choice the table scan ( is there a traceon,
command like the dbcc traceon(302) in sybase, that help you to understand
the choice of the optimizer ? ).
Thanks and sorry for my poor english.Have you tried clustering your index?
"ljbx" <pierre.lejoubioux@.nospam_atosorigin.com> wrote in message
news:1084801423.162182@.atn04...
> I have a query like this :
> select * from table
> where champs1=val1 and champs2 =val2
> I have an index on (champs1,champs2).
> The table has 698694 rows.
> The table scan cost 17770 i/os.
> If the number of rows selected is greater than 4700, the optimizer choice
> the table scan. If i force the index, i have 4762 i/os ( is less than
> 17770 )
> I don't know why the optimizer choice the table scan ( is there a traceon,
> command like the dbcc traceon(302) in sybase, that help you to understand
> the choice of the optimizer ? ).
> Thanks and sorry for my poor english.
>
>
>|||Execute this from Query Analyzer and look at the query plan. It will show
you the details... Then force the index you think is best and execute again,
compare the two.
You might try to update statistics on the table,
or drop /recreate the indices on the table and try again.
Generally however if a query returns more than 3-10% of the rows in the
table, the optimizer will choose a table scan.
--
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"ljbx" <pierre.lejoubioux@.nospam_atosorigin.com> wrote in message
news:1084801423.162182@.atn04...
> I have a query like this :
> select * from table
> where champs1=val1 and champs2 =val2
> I have an index on (champs1,champs2).
> The table has 698694 rows.
> The table scan cost 17770 i/os.
> If the number of rows selected is greater than 4700, the optimizer choice
> the table scan. If i force the index, i have 4762 i/os ( is less than
> 17770 )
> I don't know why the optimizer choice the table scan ( is there a traceon,
> command like the dbcc traceon(302) in sybase, that help you to understand
> the choice of the optimizer ? ).
> Thanks and sorry for my poor english.
>
>
>|||One possible reason is outdated statistics. Did you try UPDATE STATISTICS?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"ljbx" <pierre.lejoubioux@.nospam_atosorigin.com> wrote in message news:1084801423.162182@.atn04...
> I have a query like this :
> select * from table
> where champs1=val1 and champs2 =val2
> I have an index on (champs1,champs2).
> The table has 698694 rows.
> The table scan cost 17770 i/os.
> If the number of rows selected is greater than 4700, the optimizer choice
> the table scan. If i force the index, i have 4762 i/os ( is less than
> 17770 )
> I don't know why the optimizer choice the table scan ( is there a traceon,
> command like the dbcc traceon(302) in sybase, that help you to understand
> the choice of the optimizer ? ).
> Thanks and sorry for my poor english.
>
>
>|||there is a primary key but not on this rows
"Adam Machanic" <amachanic@.air-worldwide.nospamallowed.com> a écrit dans le
message de news:OIe9eACPEHA.3020@.tk2msftngp13.phx.gbl...
> Have you tried clustering your index?
> "ljbx" <pierre.lejoubioux@.nospam_atosorigin.com> wrote in message
> news:1084801423.162182@.atn04...
> > I have a query like this :
> >
> > select * from table
> > where champs1=val1 and champs2 =val2
> > I have an index on (champs1,champs2).
> > The table has 698694 rows.
> > The table scan cost 17770 i/os.
> >
> > If the number of rows selected is greater than 4700, the optimizer
choice
> > the table scan. If i force the index, i have 4762 i/os ( is less than
> > 17770 )
> >
> > I don't know why the optimizer choice the table scan ( is there a
traceon,
> > command like the dbcc traceon(302) in sybase, that help you to
understand
> > the choice of the optimizer ? ).
> >
> > Thanks and sorry for my poor english.
> >
> >
> >
> >
> >
> >
>

Pb table scan

I have a query like this :
select * from table
where champs1=val1 and champs2 =val2
I have an index on (champs1,champs2).
The table has 698694 rows.
The table scan cost 17770 i/os.
If the number of rows selected is greater than 4700, the optimizer choice
the table scan. If i force the index, i have 4762 i/os ( is less than
17770 )
I don't know why the optimizer choice the table scan ( is there a traceon,
command like the dbcc traceon(302) in sybase, that help you to understand
the choice of the optimizer ? ).
Thanks and sorry for my poor english.
Have you tried clustering your index?
"ljbx" <pierre.lejoubioux@.nospam_atosorigin.com> wrote in message
news:1084801423.162182@.atn04...
> I have a query like this :
> select * from table
> where champs1=val1 and champs2 =val2
> I have an index on (champs1,champs2).
> The table has 698694 rows.
> The table scan cost 17770 i/os.
> If the number of rows selected is greater than 4700, the optimizer choice
> the table scan. If i force the index, i have 4762 i/os ( is less than
> 17770 )
> I don't know why the optimizer choice the table scan ( is there a traceon,
> command like the dbcc traceon(302) in sybase, that help you to understand
> the choice of the optimizer ? ).
> Thanks and sorry for my poor english.
>
>
>
|||Execute this from Query Analyzer and look at the query plan. It will show
you the details... Then force the index you think is best and execute again,
compare the two.
You might try to update statistics on the table,
or drop /recreate the indices on the table and try again.
Generally however if a query returns more than 3-10% of the rows in the
table, the optimizer will choose a table scan.
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"ljbx" <pierre.lejoubioux@.nospam_atosorigin.com> wrote in message
news:1084801423.162182@.atn04...
> I have a query like this :
> select * from table
> where champs1=val1 and champs2 =val2
> I have an index on (champs1,champs2).
> The table has 698694 rows.
> The table scan cost 17770 i/os.
> If the number of rows selected is greater than 4700, the optimizer choice
> the table scan. If i force the index, i have 4762 i/os ( is less than
> 17770 )
> I don't know why the optimizer choice the table scan ( is there a traceon,
> command like the dbcc traceon(302) in sybase, that help you to understand
> the choice of the optimizer ? ).
> Thanks and sorry for my poor english.
>
>
>
|||One possible reason is outdated statistics. Did you try UPDATE STATISTICS?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"ljbx" <pierre.lejoubioux@.nospam_atosorigin.com> wrote in message news:1084801423.162182@.atn04...
> I have a query like this :
> select * from table
> where champs1=val1 and champs2 =val2
> I have an index on (champs1,champs2).
> The table has 698694 rows.
> The table scan cost 17770 i/os.
> If the number of rows selected is greater than 4700, the optimizer choice
> the table scan. If i force the index, i have 4762 i/os ( is less than
> 17770 )
> I don't know why the optimizer choice the table scan ( is there a traceon,
> command like the dbcc traceon(302) in sybase, that help you to understand
> the choice of the optimizer ? ).
> Thanks and sorry for my poor english.
>
>
>
|||there is a primary key but not on this rows
"Adam Machanic" <amachanic@.air-worldwide.nospamallowed.com> a crit dans le
message de news:OIe9eACPEHA.3020@.tk2msftngp13.phx.gbl...[vbcol=seagreen]
> Have you tried clustering your index?
> "ljbx" <pierre.lejoubioux@.nospam_atosorigin.com> wrote in message
> news:1084801423.162182@.atn04...
choice[vbcol=seagreen]
traceon,[vbcol=seagreen]
understand
>
sql

Passing second column of table as index

We are working on C++ in eVC++ 3.0 environment (CE 3.0) with SQL CE 2.0.

We are trying with IRowsetIndex:: Seek method to access the data from the database.

We are facing problem when we try to access data from the table having composite index other than the first column.

For example:
The table ITEM contains the following columns:
1. ItemCode
2. PcNo
3. SubPcNo
4. BrandNo
5. DescText

6. ProductionKind

7. ProductionState

8. ClearingState

9. ST

10. TS

I’ve two indexes for this table where the two indexes are

1. ItemKey1 on ITEM (ItemCode).

2. ItemKey2 on ITEM (PcNo, SubPcNo, BrandNo).

If I mention ItemKey1 as the index then the Seek method works perfectly.

But if I mention ItemKey2 as the index, then I’m getting the error as “DB_E_BADBINDINFO”.

When we visted the MSDN for this problem we noted that:

1. When you use the Seek method on multiple fields, the Seek fields must be in the same order as the fields in the underlying table. If they are not, the Seek method fails.

2. When passing key values to an index rowset, the consumer performs these actions only for the number of key columns specified in the cKeyValues argument in IRowsetIndex:: Seek.

So we had the composite index such that columns of a composite index are physically aligned next to each other as in the table.

When the first column of the index is the first column of the table as in index ItemKey1 we found that the seek method works perfectly.

If we pass the index ItemKey2, we are again getting the error “DB_E_BADBINDINFO”.

What else have we missed out while passing the keys in IRowsetIndex:: Seek?

Thanks in advance.

Regards,

Sasi.

I saw this error when tried to use the table accessor for seeking. When you use IRowsetIndex you must create a separate accessor for the index columns and use that accessor for the Seek method, not the table's own accessor.

|||

Thanks for your reply Joao Paulo Figueira.

I was not able to understand the solution you provided, could you kinldy explain in detail.

Thanks & Regards,

Sasi.

|||

You must create a second memory buffer where to store the values to seek. This is built the same way as the memory buffer for accessing table data, but it must have the index columns and in the same order. You should use code similar to the one for binding the table columns in order to create the index accessor.

The only situation when you can share the same accessor between the table and the index is when the first N columns of the index are the same as the first N columns of the table. In all other situations you must create a different accessor for entering the data to seek.

|||

Thanks a lot Sir.

Its working now.

Thanks & Regards,

Sasi.