Help! Problem with XSD mapping schema

Hello,
I have a simple mapping schema and XML document for import into MSSQL. The tables will be created on import by the bulkloader.
Im getting the cryptic error message: "Schema: invalid value for 'column' on 'bl_advertiser_listing'." when I start the import. I cant figure out why this is and I have reduced the job down to a very simple state. What 'column' is this error referring to and why? Thankyou.

The XML

<listings>
<advertiser id="470000016">
<listing>
<ibl-id>3406095</ibl-id>
</listing>
</advertiser>
</listings>

The Schema:

<xschema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlnsql="urnchemas-microsoft-com:mapping-schema">
<xs:annotation>
<xs:appinfo>
<sql:relationship name="advertiser_listings" parent="bl_advertiser" parent-key="id" child="bl_advertiser_listing" child-key="id"/>
</xs:appinfo>
</xs:annotation>
<xs:element name="listings" sql:is-constant="1">
<xs:complexType>
<xsequence>
<xs:element name="advertiser" minOccurs="0" maxOccurs="unbounded" sql:relation="bl_advertiser" sql:key-fields="id">
<xs:complexType>
<xsequence>
<xs:element name="listing" minOccurs="0" maxOccurs="unbounded" sql:relation="bl_advertiser_listing" sql:relationship="advertiser_listings">
<xs:complexType>
<xsequence>
<xs:element name="ibl-id" type="xs:integer"/>
</xsequence>
</xs:complexType>
</xs:element>
</xsequence>
<xs:attribute name="id" type="xs:integer"/>
</xs:complexType>
</xs:element>
</xsequence>
</xs:complexType>
</xs:element>
</xschema>

Moving thread...

|||I worked this out, it was quite simple! <xs:element name="ibl-id" type="xs:integer"/> is invalid since the dash - is not allowed in column names.

Help! Problem with XSD mapping schema

Hello,
I have a simple mapping schema and XML document for import into MSSQL. The tables will be created on import by the bulkloader.
Im getting the cryptic error message: "Schema: invalid value for 'column' on 'bl_advertiser_listing'." when I start the import. I cant figure out why this is and I have reduced the job down to a very simple state. What 'column' is this error referring to and why? Thankyou.

The XML

<listings>
<advertiser id="470000016">
<listing>
<ibl-id>3406095</ibl-id>
</listing>
</advertiser>
</listings>

The Schema:

<xschema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlnsql="urnchemas-microsoft-com:mapping-schema">
<xs:annotation>
<xs:appinfo>
<sql:relationship name="advertiser_listings" parent="bl_advertiser" parent-key="id" child="bl_advertiser_listing" child-key="id"/>
</xs:appinfo>
</xs:annotation>
<xs:element name="listings" sql:is-constant="1">
<xs:complexType>
<xsequence>
<xs:element name="advertiser" minOccurs="0" maxOccurs="unbounded" sql:relation="bl_advertiser" sql:key-fields="id">
<xs:complexType>
<xsequence>
<xs:element name="listing" minOccurs="0" maxOccurs="unbounded" sql:relation="bl_advertiser_listing" sql:relationship="advertiser_listings">
<xs:complexType>
<xsequence>
<xs:element name="ibl-id" type="xs:integer"/>
</xsequence>
</xs:complexType>
</xs:element>
</xsequence>
<xs:attribute name="id" type="xs:integer"/>
</xs:complexType>
</xs:element>
</xsequence>
</xs:complexType>
</xs:element>
</xschema>

Moving thread...

|||

I worked this out, it was quite simple! <xs:element name="ibl-id" type="xs:integer"/> is invalid since the dash - is not allowed in column names.

Help! Problem with XSD mapping schema

Hello,
I have a simple mapping schema and XML document for import into MSSQL. The tables will be created on import by the bulkloader.
Im getting the cryptic error message: "Schema: invalid value for 'column' on 'bl_advertiser_listing'." when I start the import. I cant figure out why this is and I have reduced the job down to a very simple state. What 'column' is this error referring to and why? Thankyou.

The XML

<listings>
<advertiser id="470000016">
<listing>
<ibl-id>3406095</ibl-id>
</listing>
</advertiser>
</listings>

The Schema:

<xschema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlnsql="urnchemas-microsoft-com:mapping-schema">
<xs:annotation>
<xs:appinfo>
<sql:relationship name="advertiser_listings" parent="bl_advertiser" parent-key="id" child="bl_advertiser_listing" child-key="id"/>
</xs:appinfo>
</xs:annotation>
<xs:element name="listings" sql:is-constant="1">
<xs:complexType>
<xsequence>
<xs:element name="advertiser" minOccurs="0" maxOccurs="unbounded" sql:relation="bl_advertiser" sql:key-fields="id">
<xs:complexType>
<xsequence>
<xs:element name="listing" minOccurs="0" maxOccurs="unbounded" sql:relation="bl_advertiser_listing" sql:relationship="advertiser_listings">
<xs:complexType>
<xsequence>
<xs:element name="ibl-id" type="xs:integer"/>
</xsequence>
</xs:complexType>
</xs:element>
</xsequence>
<xs:attribute name="id" type="xs:integer"/>
</xs:complexType>
</xs:element>
</xsequence>
</xs:complexType>
</xs:element>
</xschema>

Moving thread...

|||I worked this out, it was quite simple! <xs:element name="ibl-id" type="xs:integer"/> is invalid since the dash - is not allowed in column names.

HELP! Maintenance plan failure on ARITHABORT and QUOTED_IDENTIFIER

This has been going on for some time now. The only significant db change we
can track it to time-wise is the creation of a schema bound view for a
temporary project. This has since been deleted but the error continues so
we don't believe there to be any relation. I include the result of our
maintenance plan log here. I do not understand how it got so far into the
index rebuilds if the error is truly correct as these are database options
not table options.
Does anyone have any idea why these errors would be generated' I'm quite
concerned. I manually rebuilt the indexes from the last table listed
through all other tables in the database and received no errors.
Greatly appreciate any ideas you may have...
[1] Database IBOTree: Index Rebuild (leaving 10%% free space)...
Rebuilding indexes for table 'atempdnrefunds'
Rebuilding indexes for table 'Audit1'
Rebuilding indexes for table 'BellevueDN2004Refunds'
Rebuilding indexes for table 'helpsql'
Rebuilding indexes for table 'IBONumbersUsed'
Rebuilding indexes for table 'IBOPasswords'
Rebuilding indexes for table 'IBOTree'
Rebuilding indexes for table 'IBOTreeWithNames'
Rebuilding indexes for table 'kateupdate'
Rebuilding indexes for table 'New Table'
Rebuilding indexes for table 'Resultss'
Rebuilding indexes for table 'tblAddressQueries'
Rebuilding indexes for table 'tblAppControl'
Rebuilding indexes for table 'tblAppModules'
Rebuilding indexes for table 'tblAttendeeLegCounter'
Rebuilding indexes for table 'tblBAccomodations'
Rebuilding indexes for table 'tblBAppHotel'
Rebuilding indexes for table 'tblBApplication'
Rebuilding indexes for table 'tblBAppLocations'
Rebuilding indexes for table 'tblBAttendeeMeetings'
Rebuilding indexes for table 'tblBAttendees'
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 1934: [Microsoft]&#
91;ODBC SQL
Server Driver][SQL Server]DBCC failed because the following SET options
have
incorrect settings: 'QUOTED_IDENTIFIER, ARITHABORT'.You have a table with a calculated column or possible an indexed view.
These need certain SET conditions to be set when you access them in order
for them to work properly. The maintenance wizard can not deal correctly
with those. The solution is to create your own Reindex job that has the
settings properly set.
Andrew J. Kelly SQL MVP
"Tim Greenwood" <tim_greenwood@.yahoo.com> wrote in message
news:OzPUQRSXEHA.3988@.tk2msftngp13.phx.gbl...
> This has been going on for some time now. The only significant db change
we
> can track it to time-wise is the creation of a schema bound view for a
> temporary project. This has since been deleted but the error continues so
> we don't believe there to be any relation. I include the result of our
> maintenance plan log here. I do not understand how it got so far into the
> index rebuilds if the error is truly correct as these are database options
> not table options.
> Does anyone have any idea why these errors would be generated' I'm quite
> concerned. I manually rebuilt the indexes from the last table listed
> through all other tables in the database and received no errors.
> Greatly appreciate any ideas you may have...
> [1] Database IBOTree: Index Rebuild (leaving 10%% free space)...
> Rebuilding indexes for table 'atempdnrefunds'
> Rebuilding indexes for table 'Audit1'
> Rebuilding indexes for table 'BellevueDN2004Refunds'
> Rebuilding indexes for table 'helpsql'
> Rebuilding indexes for table 'IBONumbersUsed'
> Rebuilding indexes for table 'IBOPasswords'
> Rebuilding indexes for table 'IBOTree'
> Rebuilding indexes for table 'IBOTreeWithNames'
> Rebuilding indexes for table 'kateupdate'
> Rebuilding indexes for table 'New Table'
> Rebuilding indexes for table 'Resultss'
> Rebuilding indexes for table 'tblAddressQueries'
> Rebuilding indexes for table 'tblAppControl'
> Rebuilding indexes for table 'tblAppModules'
> Rebuilding indexes for table 'tblAttendeeLegCounter'
> Rebuilding indexes for table 'tblBAccomodations'
> Rebuilding indexes for table 'tblBAppHotel'
> Rebuilding indexes for table 'tblBApplication'
> Rebuilding indexes for table 'tblBAppLocations'
> Rebuilding indexes for table 'tblBAttendeeMeetings'
> Rebuilding indexes for table 'tblBAttendees'
> [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 1934: [Microsoft][ODB
C
SQL
> Server Driver][SQL Server]DBCC failed because the following SET options[/vbcol
]
have[vbcol=seagreen]
> incorrect settings: 'QUOTED_IDENTIFIER, ARITHABORT'.
>
>|||Thanks for the quick response. Indeed the table it fails at has several
calculated columns. I guess what confuses me is I would have assumed the
maintenance wizard was using the same dbcc dbreindex functionality that I
use from my own jobs which work fine.
Thanks again
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:eE9kesSXEHA.2636@.TK2MSFTNGP10.phx.gbl...
> You have a table with a calculated column or possible an indexed view.
> These need certain SET conditions to be set when you access them in order
> for them to work properly. The maintenance wizard can not deal correctly
> with those. The solution is to create your own Reindex job that has the
> settings properly set.
> --
> Andrew J. Kelly SQL MVP
>
> "Tim Greenwood" <tim_greenwood@.yahoo.com> wrote in message
> news:OzPUQRSXEHA.3988@.tk2msftngp13.phx.gbl...
change[vbcol=seagreen]
> we
so[vbcol=seagreen]
the[vbcol=seagreen]
options[vbcol=seagreen]
quite[vbcol=seagreen]
> SQL
> have
>|||It does use the same DBCC but it sets it's environment incorrectly and it's
hard coded.
Andrew J. Kelly SQL MVP
"Tim Greenwood" <tim_greenwood@.yahoo.com> wrote in message
news:u82%23pAVXEHA.4000@.TK2MSFTNGP09.phx.gbl...
> Thanks for the quick response. Indeed the table it fails at has several
> calculated columns. I guess what confuses me is I would have assumed the
> maintenance wizard was using the same dbcc dbreindex functionality that I
> use from my own jobs which work fine.
> Thanks again
>
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:eE9kesSXEHA.2636@.TK2MSFTNGP10.phx.gbl...
order[vbcol=seagreen]
correctly[vbcol=seagreen]
> change
continues[vbcol=seagreen]
> so
our[vbcol=seagreen]
> the
> options
> quite
[Microsoft][ODBC[vbcol=seagreen]
options[vbcol=seagreen]
>sql

HELP! Maintenance plan failure on ARITHABORT and QUOTED_IDENTIFIER

This has been going on for some time now. The only significant db change we
can track it to time-wise is the creation of a schema bound view for a
temporary project. This has since been deleted but the error continues so
we don't believe there to be any relation. I include the result of our
maintenance plan log here. I do not understand how it got so far into the
index rebuilds if the error is truly correct as these are database options
not table options.
Does anyone have any idea why these errors would be generated' I'm quite
concerned. I manually rebuilt the indexes from the last table listed
through all other tables in the database and received no errors.
Greatly appreciate any ideas you may have...
[1] Database IBOTree: Index Rebuild (leaving 10%% free space)...
Rebuilding indexes for table 'atempdnrefunds'
Rebuilding indexes for table 'Audit1'
Rebuilding indexes for table 'BellevueDN2004Refunds'
Rebuilding indexes for table 'helpsql'
Rebuilding indexes for table 'IBONumbersUsed'
Rebuilding indexes for table 'IBOPasswords'
Rebuilding indexes for table 'IBOTree'
Rebuilding indexes for table 'IBOTreeWithNames'
Rebuilding indexes for table 'kateupdate'
Rebuilding indexes for table 'New Table'
Rebuilding indexes for table 'Resultss'
Rebuilding indexes for table 'tblAddressQueries'
Rebuilding indexes for table 'tblAppControl'
Rebuilding indexes for table 'tblAppModules'
Rebuilding indexes for table 'tblAttendeeLegCounter'
Rebuilding indexes for table 'tblBAccomodations'
Rebuilding indexes for table 'tblBAppHotel'
Rebuilding indexes for table 'tblBApplication'
Rebuilding indexes for table 'tblBAppLocations'
Rebuilding indexes for table 'tblBAttendeeMeetings'
Rebuilding indexes for table 'tblBAttendees'
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 1934: [Microsoft][ODBC SQL
Server Driver][SQL Server]DBCC failed because the following SET options have
incorrect settings: 'QUOTED_IDENTIFIER, ARITHABORT'.You have a table with a calculated column or possible an indexed view.
These need certain SET conditions to be set when you access them in order
for them to work properly. The maintenance wizard can not deal correctly
with those. The solution is to create your own Reindex job that has the
settings properly set.
--
Andrew J. Kelly SQL MVP
"Tim Greenwood" <tim_greenwood@.yahoo.com> wrote in message
news:OzPUQRSXEHA.3988@.tk2msftngp13.phx.gbl...
> This has been going on for some time now. The only significant db change
we
> can track it to time-wise is the creation of a schema bound view for a
> temporary project. This has since been deleted but the error continues so
> we don't believe there to be any relation. I include the result of our
> maintenance plan log here. I do not understand how it got so far into the
> index rebuilds if the error is truly correct as these are database options
> not table options.
> Does anyone have any idea why these errors would be generated' I'm quite
> concerned. I manually rebuilt the indexes from the last table listed
> through all other tables in the database and received no errors.
> Greatly appreciate any ideas you may have...
> [1] Database IBOTree: Index Rebuild (leaving 10%% free space)...
> Rebuilding indexes for table 'atempdnrefunds'
> Rebuilding indexes for table 'Audit1'
> Rebuilding indexes for table 'BellevueDN2004Refunds'
> Rebuilding indexes for table 'helpsql'
> Rebuilding indexes for table 'IBONumbersUsed'
> Rebuilding indexes for table 'IBOPasswords'
> Rebuilding indexes for table 'IBOTree'
> Rebuilding indexes for table 'IBOTreeWithNames'
> Rebuilding indexes for table 'kateupdate'
> Rebuilding indexes for table 'New Table'
> Rebuilding indexes for table 'Resultss'
> Rebuilding indexes for table 'tblAddressQueries'
> Rebuilding indexes for table 'tblAppControl'
> Rebuilding indexes for table 'tblAppModules'
> Rebuilding indexes for table 'tblAttendeeLegCounter'
> Rebuilding indexes for table 'tblBAccomodations'
> Rebuilding indexes for table 'tblBAppHotel'
> Rebuilding indexes for table 'tblBApplication'
> Rebuilding indexes for table 'tblBAppLocations'
> Rebuilding indexes for table 'tblBAttendeeMeetings'
> Rebuilding indexes for table 'tblBAttendees'
> [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 1934: [Microsoft][ODBC
SQL
> Server Driver][SQL Server]DBCC failed because the following SET options
have
> incorrect settings: 'QUOTED_IDENTIFIER, ARITHABORT'.
>
>|||Thanks for the quick response. Indeed the table it fails at has several
calculated columns. I guess what confuses me is I would have assumed the
maintenance wizard was using the same dbcc dbreindex functionality that I
use from my own jobs which work fine.
Thanks again
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:eE9kesSXEHA.2636@.TK2MSFTNGP10.phx.gbl...
> You have a table with a calculated column or possible an indexed view.
> These need certain SET conditions to be set when you access them in order
> for them to work properly. The maintenance wizard can not deal correctly
> with those. The solution is to create your own Reindex job that has the
> settings properly set.
> --
> Andrew J. Kelly SQL MVP
>
> "Tim Greenwood" <tim_greenwood@.yahoo.com> wrote in message
> news:OzPUQRSXEHA.3988@.tk2msftngp13.phx.gbl...
> > This has been going on for some time now. The only significant db
change
> we
> > can track it to time-wise is the creation of a schema bound view for a
> > temporary project. This has since been deleted but the error continues
so
> > we don't believe there to be any relation. I include the result of our
> > maintenance plan log here. I do not understand how it got so far into
the
> > index rebuilds if the error is truly correct as these are database
options
> > not table options.
> >
> > Does anyone have any idea why these errors would be generated' I'm
quite
> > concerned. I manually rebuilt the indexes from the last table listed
> > through all other tables in the database and received no errors.
> >
> > Greatly appreciate any ideas you may have...
> >
> > [1] Database IBOTree: Index Rebuild (leaving 10%% free space)...
> >
> > Rebuilding indexes for table 'atempdnrefunds'
> > Rebuilding indexes for table 'Audit1'
> > Rebuilding indexes for table 'BellevueDN2004Refunds'
> > Rebuilding indexes for table 'helpsql'
> > Rebuilding indexes for table 'IBONumbersUsed'
> > Rebuilding indexes for table 'IBOPasswords'
> > Rebuilding indexes for table 'IBOTree'
> > Rebuilding indexes for table 'IBOTreeWithNames'
> > Rebuilding indexes for table 'kateupdate'
> > Rebuilding indexes for table 'New Table'
> > Rebuilding indexes for table 'Resultss'
> > Rebuilding indexes for table 'tblAddressQueries'
> > Rebuilding indexes for table 'tblAppControl'
> > Rebuilding indexes for table 'tblAppModules'
> > Rebuilding indexes for table 'tblAttendeeLegCounter'
> > Rebuilding indexes for table 'tblBAccomodations'
> > Rebuilding indexes for table 'tblBAppHotel'
> > Rebuilding indexes for table 'tblBApplication'
> > Rebuilding indexes for table 'tblBAppLocations'
> > Rebuilding indexes for table 'tblBAttendeeMeetings'
> > Rebuilding indexes for table 'tblBAttendees'
> > [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 1934: [Microsoft][ODBC
> SQL
> > Server Driver][SQL Server]DBCC failed because the following SET options
> have
> > incorrect settings: 'QUOTED_IDENTIFIER, ARITHABORT'.
> >
> >
> >
>|||It does use the same DBCC but it sets it's environment incorrectly and it's
hard coded.
--
Andrew J. Kelly SQL MVP
"Tim Greenwood" <tim_greenwood@.yahoo.com> wrote in message
news:u82%23pAVXEHA.4000@.TK2MSFTNGP09.phx.gbl...
> Thanks for the quick response. Indeed the table it fails at has several
> calculated columns. I guess what confuses me is I would have assumed the
> maintenance wizard was using the same dbcc dbreindex functionality that I
> use from my own jobs which work fine.
> Thanks again
>
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:eE9kesSXEHA.2636@.TK2MSFTNGP10.phx.gbl...
> > You have a table with a calculated column or possible an indexed view.
> > These need certain SET conditions to be set when you access them in
order
> > for them to work properly. The maintenance wizard can not deal
correctly
> > with those. The solution is to create your own Reindex job that has the
> > settings properly set.
> >
> > --
> > Andrew J. Kelly SQL MVP
> >
> >
> > "Tim Greenwood" <tim_greenwood@.yahoo.com> wrote in message
> > news:OzPUQRSXEHA.3988@.tk2msftngp13.phx.gbl...
> > > This has been going on for some time now. The only significant db
> change
> > we
> > > can track it to time-wise is the creation of a schema bound view for a
> > > temporary project. This has since been deleted but the error
continues
> so
> > > we don't believe there to be any relation. I include the result of
our
> > > maintenance plan log here. I do not understand how it got so far into
> the
> > > index rebuilds if the error is truly correct as these are database
> options
> > > not table options.
> > >
> > > Does anyone have any idea why these errors would be generated' I'm
> quite
> > > concerned. I manually rebuilt the indexes from the last table listed
> > > through all other tables in the database and received no errors.
> > >
> > > Greatly appreciate any ideas you may have...
> > >
> > > [1] Database IBOTree: Index Rebuild (leaving 10%% free space)...
> > >
> > > Rebuilding indexes for table 'atempdnrefunds'
> > > Rebuilding indexes for table 'Audit1'
> > > Rebuilding indexes for table 'BellevueDN2004Refunds'
> > > Rebuilding indexes for table 'helpsql'
> > > Rebuilding indexes for table 'IBONumbersUsed'
> > > Rebuilding indexes for table 'IBOPasswords'
> > > Rebuilding indexes for table 'IBOTree'
> > > Rebuilding indexes for table 'IBOTreeWithNames'
> > > Rebuilding indexes for table 'kateupdate'
> > > Rebuilding indexes for table 'New Table'
> > > Rebuilding indexes for table 'Resultss'
> > > Rebuilding indexes for table 'tblAddressQueries'
> > > Rebuilding indexes for table 'tblAppControl'
> > > Rebuilding indexes for table 'tblAppModules'
> > > Rebuilding indexes for table 'tblAttendeeLegCounter'
> > > Rebuilding indexes for table 'tblBAccomodations'
> > > Rebuilding indexes for table 'tblBAppHotel'
> > > Rebuilding indexes for table 'tblBApplication'
> > > Rebuilding indexes for table 'tblBAppLocations'
> > > Rebuilding indexes for table 'tblBAttendeeMeetings'
> > > Rebuilding indexes for table 'tblBAttendees'
> > > [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 1934:
[Microsoft][ODBC
> > SQL
> > > Server Driver][SQL Server]DBCC failed because the following SET
options
> > have
> > > incorrect settings: 'QUOTED_IDENTIFIER, ARITHABORT'.
> > >
> > >
> > >
> >
> >
>

HELP! Maintenance plan failure on ARITHABORT and QUOTED_IDENTIFIER

This has been going on for some time now. The only significant db change we
can track it to time-wise is the creation of a schema bound view for a
temporary project. This has since been deleted but the error continues so
we don't believe there to be any relation. I include the result of our
maintenance plan log here. I do not understand how it got so far into the
index rebuilds if the error is truly correct as these are database options
not table options.
Does anyone have any idea why these errors would be generated? I'm quite
concerned. I manually rebuilt the indexes from the last table listed
through all other tables in the database and received no errors.
Greatly appreciate any ideas you may have...
[1] Database IBOTree: Index Rebuild (leaving 10%% free space)...
Rebuilding indexes for table 'atempdnrefunds'
Rebuilding indexes for table 'Audit1'
Rebuilding indexes for table 'BellevueDN2004Refunds'
Rebuilding indexes for table 'helpsql'
Rebuilding indexes for table 'IBONumbersUsed'
Rebuilding indexes for table 'IBOPasswords'
Rebuilding indexes for table 'IBOTree'
Rebuilding indexes for table 'IBOTreeWithNames'
Rebuilding indexes for table 'kateupdate'
Rebuilding indexes for table 'New Table'
Rebuilding indexes for table 'Resultss'
Rebuilding indexes for table 'tblAddressQueries'
Rebuilding indexes for table 'tblAppControl'
Rebuilding indexes for table 'tblAppModules'
Rebuilding indexes for table 'tblAttendeeLegCounter'
Rebuilding indexes for table 'tblBAccomodations'
Rebuilding indexes for table 'tblBAppHotel'
Rebuilding indexes for table 'tblBApplication'
Rebuilding indexes for table 'tblBAppLocations'
Rebuilding indexes for table 'tblBAttendeeMeetings'
Rebuilding indexes for table 'tblBAttendees'
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 1934: [Microsoft][ODBC SQL
Server Driver][SQL Server]DBCC failed because the following SET options have
incorrect settings: 'QUOTED_IDENTIFIER, ARITHABORT'.
You have a table with a calculated column or possible an indexed view.
These need certain SET conditions to be set when you access them in order
for them to work properly. The maintenance wizard can not deal correctly
with those. The solution is to create your own Reindex job that has the
settings properly set.
Andrew J. Kelly SQL MVP
"Tim Greenwood" <tim_greenwood@.yahoo.com> wrote in message
news:OzPUQRSXEHA.3988@.tk2msftngp13.phx.gbl...
> This has been going on for some time now. The only significant db change
we
> can track it to time-wise is the creation of a schema bound view for a
> temporary project. This has since been deleted but the error continues so
> we don't believe there to be any relation. I include the result of our
> maintenance plan log here. I do not understand how it got so far into the
> index rebuilds if the error is truly correct as these are database options
> not table options.
> Does anyone have any idea why these errors would be generated? I'm quite
> concerned. I manually rebuilt the indexes from the last table listed
> through all other tables in the database and received no errors.
> Greatly appreciate any ideas you may have...
> [1] Database IBOTree: Index Rebuild (leaving 10%% free space)...
> Rebuilding indexes for table 'atempdnrefunds'
> Rebuilding indexes for table 'Audit1'
> Rebuilding indexes for table 'BellevueDN2004Refunds'
> Rebuilding indexes for table 'helpsql'
> Rebuilding indexes for table 'IBONumbersUsed'
> Rebuilding indexes for table 'IBOPasswords'
> Rebuilding indexes for table 'IBOTree'
> Rebuilding indexes for table 'IBOTreeWithNames'
> Rebuilding indexes for table 'kateupdate'
> Rebuilding indexes for table 'New Table'
> Rebuilding indexes for table 'Resultss'
> Rebuilding indexes for table 'tblAddressQueries'
> Rebuilding indexes for table 'tblAppControl'
> Rebuilding indexes for table 'tblAppModules'
> Rebuilding indexes for table 'tblAttendeeLegCounter'
> Rebuilding indexes for table 'tblBAccomodations'
> Rebuilding indexes for table 'tblBAppHotel'
> Rebuilding indexes for table 'tblBApplication'
> Rebuilding indexes for table 'tblBAppLocations'
> Rebuilding indexes for table 'tblBAttendeeMeetings'
> Rebuilding indexes for table 'tblBAttendees'
> [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 1934: [Microsoft][ODBC
SQL
> Server Driver][SQL Server]DBCC failed because the following SET options
have
> incorrect settings: 'QUOTED_IDENTIFIER, ARITHABORT'.
>
>
|||You have a table with a calculated column or possible an indexed view.
These need certain SET conditions to be set when you access them in order
for them to work properly. The maintenance wizard can not deal correctly
with those. The solution is to create your own Reindex job that has the
settings properly set.
Andrew J. Kelly SQL MVP
"Tim Greenwood" <tim_greenwood@.yahoo.com> wrote in message
news:OzPUQRSXEHA.3988@.tk2msftngp13.phx.gbl...
> This has been going on for some time now. The only significant db change
we
> can track it to time-wise is the creation of a schema bound view for a
> temporary project. This has since been deleted but the error continues so
> we don't believe there to be any relation. I include the result of our
> maintenance plan log here. I do not understand how it got so far into the
> index rebuilds if the error is truly correct as these are database options
> not table options.
> Does anyone have any idea why these errors would be generated? I'm quite
> concerned. I manually rebuilt the indexes from the last table listed
> through all other tables in the database and received no errors.
> Greatly appreciate any ideas you may have...
> [1] Database IBOTree: Index Rebuild (leaving 10%% free space)...
> Rebuilding indexes for table 'atempdnrefunds'
> Rebuilding indexes for table 'Audit1'
> Rebuilding indexes for table 'BellevueDN2004Refunds'
> Rebuilding indexes for table 'helpsql'
> Rebuilding indexes for table 'IBONumbersUsed'
> Rebuilding indexes for table 'IBOPasswords'
> Rebuilding indexes for table 'IBOTree'
> Rebuilding indexes for table 'IBOTreeWithNames'
> Rebuilding indexes for table 'kateupdate'
> Rebuilding indexes for table 'New Table'
> Rebuilding indexes for table 'Resultss'
> Rebuilding indexes for table 'tblAddressQueries'
> Rebuilding indexes for table 'tblAppControl'
> Rebuilding indexes for table 'tblAppModules'
> Rebuilding indexes for table 'tblAttendeeLegCounter'
> Rebuilding indexes for table 'tblBAccomodations'
> Rebuilding indexes for table 'tblBAppHotel'
> Rebuilding indexes for table 'tblBApplication'
> Rebuilding indexes for table 'tblBAppLocations'
> Rebuilding indexes for table 'tblBAttendeeMeetings'
> Rebuilding indexes for table 'tblBAttendees'
> [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 1934: [Microsoft][ODBC
SQL
> Server Driver][SQL Server]DBCC failed because the following SET options
have
> incorrect settings: 'QUOTED_IDENTIFIER, ARITHABORT'.
>
>
|||Thanks for the quick response. Indeed the table it fails at has several
calculated columns. I guess what confuses me is I would have assumed the
maintenance wizard was using the same dbcc dbreindex functionality that I
use from my own jobs which work fine.
Thanks again
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:eE9kesSXEHA.2636@.TK2MSFTNGP10.phx.gbl...[vbcol=seagreen]
> You have a table with a calculated column or possible an indexed view.
> These need certain SET conditions to be set when you access them in order
> for them to work properly. The maintenance wizard can not deal correctly
> with those. The solution is to create your own Reindex job that has the
> settings properly set.
> --
> Andrew J. Kelly SQL MVP
>
> "Tim Greenwood" <tim_greenwood@.yahoo.com> wrote in message
> news:OzPUQRSXEHA.3988@.tk2msftngp13.phx.gbl...
change[vbcol=seagreen]
> we
so[vbcol=seagreen]
the[vbcol=seagreen]
options[vbcol=seagreen]
quite
> SQL
> have
>
|||Thanks for the quick response. Indeed the table it fails at has several
calculated columns. I guess what confuses me is I would have assumed the
maintenance wizard was using the same dbcc dbreindex functionality that I
use from my own jobs which work fine.
Thanks again
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:eE9kesSXEHA.2636@.TK2MSFTNGP10.phx.gbl...[vbcol=seagreen]
> You have a table with a calculated column or possible an indexed view.
> These need certain SET conditions to be set when you access them in order
> for them to work properly. The maintenance wizard can not deal correctly
> with those. The solution is to create your own Reindex job that has the
> settings properly set.
> --
> Andrew J. Kelly SQL MVP
>
> "Tim Greenwood" <tim_greenwood@.yahoo.com> wrote in message
> news:OzPUQRSXEHA.3988@.tk2msftngp13.phx.gbl...
change[vbcol=seagreen]
> we
so[vbcol=seagreen]
the[vbcol=seagreen]
options[vbcol=seagreen]
quite
> SQL
> have
>
|||It does use the same DBCC but it sets it's environment incorrectly and it's
hard coded.
Andrew J. Kelly SQL MVP
"Tim Greenwood" <tim_greenwood@.yahoo.com> wrote in message
news:u82%23pAVXEHA.4000@.TK2MSFTNGP09.phx.gbl...[vbcol=seagreen]
> Thanks for the quick response. Indeed the table it fails at has several
> calculated columns. I guess what confuses me is I would have assumed the
> maintenance wizard was using the same dbcc dbreindex functionality that I
> use from my own jobs which work fine.
> Thanks again
>
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:eE9kesSXEHA.2636@.TK2MSFTNGP10.phx.gbl...
order[vbcol=seagreen]
correctly[vbcol=seagreen]
> change
continues[vbcol=seagreen]
> so
our[vbcol=seagreen]
> the
> options
> quite
[Microsoft][ODBC[vbcol=seagreen]
options
>
|||It does use the same DBCC but it sets it's environment incorrectly and it's
hard coded.
Andrew J. Kelly SQL MVP
"Tim Greenwood" <tim_greenwood@.yahoo.com> wrote in message
news:u82%23pAVXEHA.4000@.TK2MSFTNGP09.phx.gbl...[vbcol=seagreen]
> Thanks for the quick response. Indeed the table it fails at has several
> calculated columns. I guess what confuses me is I would have assumed the
> maintenance wizard was using the same dbcc dbreindex functionality that I
> use from my own jobs which work fine.
> Thanks again
>
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:eE9kesSXEHA.2636@.TK2MSFTNGP10.phx.gbl...
order[vbcol=seagreen]
correctly[vbcol=seagreen]
> change
continues[vbcol=seagreen]
> so
our[vbcol=seagreen]
> the
> options
> quite
[Microsoft][ODBC[vbcol=seagreen]
options
>

HELP! Dynamic binding of schema element names

Hi all,
Somehow I lost the thread where I originally posted this query. Thanks
Erland and GregO for your answers. Very helpful indeed.
Although I think I can solve my problem with what you guys suggested, I'd
really like to know your opinion and maybe offer solutions
of achieving my goal. Let me put my problem forth in more detail:
My application has all it's logic in a COM component and all SQL queries are
issued from there.
The application itself was never designed with security and access-control
in mind
(which I'm cursing it for and have to incorporate now :-(( ). So, now I have
a
few thousand queries that I don't want to affect drastically.
I have a bunch of users in a [USER] table and a bunch of resources in a
[RESOURCE] table. What ultimately should happen is that
every user should be able to see resources only entitled to her based on
some security policy.
Here is how I think it can be done.
A new entity [SEC_GROUP] can be introduced where each user is part of one or
more security groups. For each security group,
I will create a view on the [RESOURCE] table: [admingrp_resource],
[generaluser_resource] and so on.
So, when a user issues a query like,
SELECT * FROM [RESOURCE]
I will actually substitute [RESOURCE] with a function like
get_resource_view(userid)
EXEC( 'SELECT * FROM ' + get_resource_view(userid))
The get_resource_view( ) function would get the appropriate resource view
for the user based on her security group.
The above would be rather easy if the user is part of only one security
group. If there are more, I might have to do
some unions. This would impact the queries quite a bit, but I can't think of
another way to implement this.
Once again, thanks for your responses, I appreciate your help and looking
forward to more suggestions.
Best regards,
--Abhi
Abhijith Das (adas@.expeditevcs.com) writes:
> I'm trying to achieve the following using SQL and SQLServer2000 is the db
> I'm using.
>
> Here's a simple select statement
>
> SELECT column1, column2 FROM my_table WHERE some_condition = 1
>
> What I want to be able to do is bind the name my_table to an actual
> tablename during runtime, i.e. when the query executes.
> The equivalent effect of what I'd like can be represented as below:
>
> SELECT column1, column2 FROM get_my_table_name( ) WHERE some_condition = > 1.
>
> Here get_my_table_name( ) is a function that evaluates and returns the
> table name. Things don't work this way however. Is there a way to
> accomplish this?
Yes. But it is unlikely that it is the right thing to do. Since I don't
know your underlying problem, I cannot suggest a solution here and now.
But this article on my web site, both describes on how you can achieve
this - and why you most probably should not do it anyway.
http://www.sommarskog.se/dynamic_sql.html.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.aspAbhijith Das (adas@.expeditevcs.com) writes:
> My application has all it's logic in a COM component and all SQL queries
> are issued from there. The application itself was never designed with
> security and access-control in mind (which I'm cursing it for and have
> to incorporate now :-(( ). So, now I have a few thousand queries that I
> don't want to affect drastically.
> I have a bunch of users in a [USER] table and a bunch of resources in a
> [RESOURCE] table. What ultimately should happen is that every user
> should be able to see resources only entitled to her based on some
> security policy. Here is how I think it can be done. A new entity
> [SEC_GROUP] can be introduced where each user is part of one or more
> security groups. For each security group, I will create a view on the
> [RESOURCE] table: [admingrp_resource], [generaluser_resource] and so
> on.
First of all, for this to be meaningful, you need to revoke access to
the tables from the users. Keep in mind that there are other means to
connecting to SQL Server, and a skilled user could for instance use
Query Analyzer to access the data.
> So, when a user issues a query like,
> SELECT * FROM [RESOURCE]
> I will actually substitute [RESOURCE] with a function like
> get_resource_view(userid)
> EXEC( 'SELECT * FROM ' + get_resource_view(userid))
But why do you want to have this function in SQL? Since you apparently
have all your logic client-side, why not stick to that? Depending on
the size of the data stored for these security groups, you could read
this data once, and keep it in memory. (May need some refresh mechanism
in case the security configuration is changed.)
From this follows that the user will need to have SELECT access to
the table what defines the security groups and the resources. (Unless
you use an application role.)
> The get_resource_view( ) function would get the appropriate resource
> view for the user based on her security group. The above would be rather
> easy if the user is part of only one security group. If there are more,
> I might have to do some unions. This would impact the queries quite a
> bit, but I can't think of another way to implement this.
A common approach to row-level security is to have views that includes
conditions like:
AND userid = SYSTEM_USER
Although one should be aware of that a skilled user with a query tool can
still be able to carve out glimpses of data he is not intended to see.
For a more complex security scheme, you could have table-valued
functions, but you would have to one for each base table.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp

HELP! Dynamic binding of schema element names

Hi all,
I'm trying to achieve the following using SQL and SQLServer2000 is the db
I'm using.
Here's a simple select statement
SELECT column1, column2 FROM my_table WHERE some_condition = 1
What I want to be able to do is bind the name my_table to an actual
tablename during runtime, i.e. when the query executes.
The equivalent effect of what I'd like can be represented as below:
SELECT column1, column2 FROM get_my_table_name( ) WHERE some_condition = 1.
Here get_my_table_name( ) is a function that evaluates and returns the table
name. Things don't work this way however.
Is there a way to accomplish this?
Any replies are greatly appreciated.
Thanks in advance,
--Abhi[posted and mailed, please reply in news]
Abhijith Das (adas@.expeditevcs.com) writes:
> I'm trying to achieve the following using SQL and SQLServer2000 is the db
> I'm using.
> Here's a simple select statement
> SELECT column1, column2 FROM my_table WHERE some_condition = 1
> What I want to be able to do is bind the name my_table to an actual
> tablename during runtime, i.e. when the query executes.
> The equivalent effect of what I'd like can be represented as below:
> SELECT column1, column2 FROM get_my_table_name( ) WHERE some_condition => 1.
> Here get_my_table_name( ) is a function that evaluates and returns the
> table name. Things don't work this way however. Is there a way to
> accomplish this?
Yes. But it is unlikely that it is the right thing to do. Since I don't
know your underlying problem, I cannot suggest a solution here and now.
But this article on my web site, both describes on how you can achieve
this - and why you most probably should not do it anyway.
http://www.sommarskog.se/dynamic_sql.html.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp|||Hi ,
No you can't do that that way. You must use dynamic SQL something like this
Declare @.SQL varchar(1000)
set @.SQL = 'SELECT column1, column2 FROM ' + 'my_table' + ' WHERE
some_condition = 1'
exec @.SQL
--
kind regards
Greg O
Need to document your databases. Use the firs and still the best AGS SQL
Scribe
http://www.ag-software.com
"Abhijith Das" <adas@.expeditevcs.com> wrote in message
news:u400jnbqFHA.544@.TK2MSFTNGP11.phx.gbl...
> Hi all,
> I'm trying to achieve the following using SQL and SQLServer2000 is the db
> I'm using.
> Here's a simple select statement
> SELECT column1, column2 FROM my_table WHERE some_condition = 1
> What I want to be able to do is bind the name my_table to an actual
> tablename during runtime, i.e. when the query executes.
> The equivalent effect of what I'd like can be represented as below:
> SELECT column1, column2 FROM get_my_table_name( ) WHERE some_condition => 1.
> Here get_my_table_name( ) is a function that evaluates and returns the
> table name. Things don't work this way however.
> Is there a way to accomplish this?
> Any replies are greatly appreciated.
> Thanks in advance,
> --Abhi
>

HELP! Dynamic binding of schema element names

Hi all,
I'm trying to achieve the following using SQL and SQLServer2000 is the db
I'm using.
Here's a simple select statement
SELECT column1, column2 FROM my_table WHERE some_condition = 1
What I want to be able to do is bind the name my_table to an actual
tablename during runtime, i.e. when the query executes.
The equivalent effect of what I'd like can be represented as below:
SELECT column1, column2 FROM get_my_table_name( ) WHERE some_condition = 1.
Here get_my_table_name( ) is a function that evaluates and returns the table
name. Things don't work this way however.
Is there a way to accomplish this?
Any replies are greatly appreciated.
Thanks in advance,
--Abhi
Hi ,
No you can't do that that way. You must use dynamic SQL something like this
Declare @.SQL varchar(1000)
set @.SQL = 'SELECT column1, column2 FROM ' + 'my_table' + ' WHERE
some_condition = 1'
exec @.SQL
kind regards
Greg O
Need to document your databases. Use the firs and still the best AGS SQL
Scribe
http://www.ag-software.com
"Abhijith Das" <adas@.expeditevcs.com> wrote in message
news:u400jnbqFHA.544@.TK2MSFTNGP11.phx.gbl...
> Hi all,
> I'm trying to achieve the following using SQL and SQLServer2000 is the db
> I'm using.
> Here's a simple select statement
> SELECT column1, column2 FROM my_table WHERE some_condition = 1
> What I want to be able to do is bind the name my_table to an actual
> tablename during runtime, i.e. when the query executes.
> The equivalent effect of what I'd like can be represented as below:
> SELECT column1, column2 FROM get_my_table_name( ) WHERE some_condition =
> 1.
> Here get_my_table_name( ) is a function that evaluates and returns the
> table name. Things don't work this way however.
> Is there a way to accomplish this?
> Any replies are greatly appreciated.
> Thanks in advance,
> --Abhi
>
|||[posted and mailed, please reply in news]
Abhijith Das (adas@.expeditevcs.com) writes:
> I'm trying to achieve the following using SQL and SQLServer2000 is the db
> I'm using.
> Here's a simple select statement
> SELECT column1, column2 FROM my_table WHERE some_condition = 1
> What I want to be able to do is bind the name my_table to an actual
> tablename during runtime, i.e. when the query executes.
> The equivalent effect of what I'd like can be represented as below:
> SELECT column1, column2 FROM get_my_table_name( ) WHERE some_condition =
> 1.
> Here get_my_table_name( ) is a function that evaluates and returns the
> table name. Things don't work this way however. Is there a way to
> accomplish this?
Yes. But it is unlikely that it is the right thing to do. Since I don't
know your underlying problem, I cannot suggest a solution here and now.
But this article on my web site, both describes on how you can achieve
this - and why you most probably should not do it anyway.
http://www.sommarskog.se/dynamic_sql.html.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp
|||Hi all,
Somehow I lost the thread where I originally posted this query. Thanks
Erland and GregO for your answers. Very helpful indeed.
Although I think I can solve my problem with what you guys suggested, I'd
really like to know your opinion and maybe offer solutions
of achieving my goal. Let me put my problem forth in more detail:
My application has all it's logic in a COM component and all SQL queries are
issued from there.
The application itself was never designed with security and access-control
in mind
(which I'm cursing it for and have to incorporate now :-(( ). So, now I have
a
few thousand queries that I don't want to affect drastically.
I have a bunch of users in a [USER] table and a bunch of resources in a
[RESOURCE] table. What ultimately should happen is that
every user should be able to see resources only entitled to her based on
some security policy.
Here is how I think it can be done.
A new entity [SEC_GROUP] can be introduced where each user is part of one or
more security groups. For each security group,
I will create a view on the [RESOURCE] table: [admingrp_resource],
[generaluser_resource] and so on.
So, when a user issues a query like,
SELECT * FROM [RESOURCE]
I will actually substitute [RESOURCE] with a function like
get_resource_view(userid)
EXEC( 'SELECT * FROM ' + get_resource_view(userid))
The get_resource_view( ) function would get the appropriate resource view
for the user based on her security group.
The above would be rather easy if the user is part of only one security
group. If there are more, I might have to do
some unions. This would impact the queries quite a bit, but I can't think of
another way to implement this.
Once again, thanks for your responses, I appreciate your help and looking
forward to more suggestions.
Best regards,
--Abhi
Abhijith Das (adas@.expeditevcs.com) writes:
> I'm trying to achieve the following using SQL and SQLServer2000 is the db
> I'm using.
> Here's a simple select statement
> SELECT column1, column2 FROM my_table WHERE some_condition = 1
> What I want to be able to do is bind the name my_table to an actual
> tablename during runtime, i.e. when the query executes.
> The equivalent effect of what I'd like can be represented as below:
> SELECT column1, column2 FROM get_my_table_name( ) WHERE some_condition =
> 1.
> Here get_my_table_name( ) is a function that evaluates and returns the
> table name. Things don't work this way however. Is there a way to
> accomplish this?
Yes. But it is unlikely that it is the right thing to do. Since I don't
know your underlying problem, I cannot suggest a solution here and now.
But this article on my web site, both describes on how you can achieve
this - and why you most probably should not do it anyway.
http://www.sommarskog.se/dynamic_sql.html.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp
|||Abhijith Das (adas@.expeditevcs.com) writes:
> My application has all it's logic in a COM component and all SQL queries
> are issued from there. The application itself was never designed with
> security and access-control in mind (which I'm cursing it for and have
> to incorporate now :-(( ). So, now I have a few thousand queries that I
> don't want to affect drastically.
> I have a bunch of users in a [USER] table and a bunch of resources in a
> [RESOURCE] table. What ultimately should happen is that every user
> should be able to see resources only entitled to her based on some
> security policy. Here is how I think it can be done. A new entity
> [SEC_GROUP] can be introduced where each user is part of one or more
> security groups. For each security group, I will create a view on the
> [RESOURCE] table: [admingrp_resource], [generaluser_resource] and so
> on.
First of all, for this to be meaningful, you need to revoke access to
the tables from the users. Keep in mind that there are other means to
connecting to SQL Server, and a skilled user could for instance use
Query Analyzer to access the data.

> So, when a user issues a query like,
> SELECT * FROM [RESOURCE]
> I will actually substitute [RESOURCE] with a function like
> get_resource_view(userid)
> EXEC( 'SELECT * FROM ' + get_resource_view(userid))
But why do you want to have this function in SQL? Since you apparently
have all your logic client-side, why not stick to that? Depending on
the size of the data stored for these security groups, you could read
this data once, and keep it in memory. (May need some refresh mechanism
in case the security configuration is changed.)
From this follows that the user will need to have SELECT access to
the table what defines the security groups and the resources. (Unless
you use an application role.)

> The get_resource_view( ) function would get the appropriate resource
> view for the user based on her security group. The above would be rather
> easy if the user is part of only one security group. If there are more,
> I might have to do some unions. This would impact the queries quite a
> bit, but I can't think of another way to implement this.
A common approach to row-level security is to have views that includes
conditions like:
AND userid = SYSTEM_USER
Although one should be aware of that a skilled user with a query tool can
still be able to carve out glimpses of data he is not intended to see.
For a more complex security scheme, you could have table-valued
functions, but you would have to one for each base table.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

HELP! " the table schema changed after the cursor was declared"

I have a DTS package working from backend and command line. Then I did an enhancement. It works from backend but not from command line. The error says:

Step Error Description:Could not complete cursor operation because the table schema changed after the cursor was declared.

But I don't see "table schema" change?!! Any idea?

Thanks,

LiliOriginally posted by lili3000
I have a DTS package working from backend and command line. Then I did an enhancement. It works from backend but not from command line. The error says:

Step Error Description:Could not complete cursor operation because the table schema changed after the cursor was declared.

But I don't see "table schema" change?!! Any idea?

Thanks,

Lili

I ran in to the same problem. As it turned out I was running the application at 1:00 am to process credit card transaction (This application is a batched response from shipper) Anyway. I had inadvertly schedule maintence during this time. The problem was resolved by moving the Maintence time.

I hope this helps.

Terry