|
database
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
scripts fails under ADO but no error returned.if not EXISTS ( SELECT * FROM dbo.syscolumns WHERE (name = N'owner') and id = (SELECT id from dbo.sysobjects where name = 'models')) begin -- several steps here omitted ALTER TABLE dbo.Accounts DROP COLUMN [id] -- More steps here End The problem is that this alter table command fails if we miss an index that uses id. THe script seems to end executino there but the call to the ADO ConnectionPtr->Execute command does not report failure. It returns S_OK. Is there some special way to get these failures reported from ADO? TIA Otis Bricker Otis Bricker <obric***@my-dejanews.com> wrote in
Show quote news:Xns98067B5C6C3A2obrickermydejanewsco@216.196.97.136: Sorry, I had meant to say that the script does not seem to stop exection > > I am trying to run a script through ADO that changes the schema of a > table. > > > if not EXISTS ( SELECT * > FROM dbo.syscolumns > WHERE (name = N'owner') and id = (SELECT id from > dbo.sysobjects > > where name = 'models')) > begin > > -- several steps here omitted > > ALTER TABLE dbo.Accounts DROP COLUMN [id] > > -- More steps here > > End > > The problem is that this alter table command fails if we miss an index > that uses id. THe script seems to end executino there but the call to > the ADO ConnectionPtr->Execute command does not report failure. It > returns S_OK. > there while in QAnalyser it does. Show quote > Is there some special way to get these failures reported from ADO? > > TIA > > Otis Bricker > > > > > Otis Bricker wrote:
Show quote > I am trying to run a script through ADO that changes the schema of a table. This seems sort of questionable to me - why are you altering a table > > > if not EXISTS ( SELECT * > FROM dbo.syscolumns > WHERE (name = N'owner') and id = (SELECT id from dbo.sysobjects > where name = 'models')) > begin > > -- several steps here omitted > > ALTER TABLE dbo.Accounts DROP COLUMN [id] > > -- More steps here > > End > > The problem is that this alter table command fails if we miss an index that > uses id. THe script seems to end executino there but the call to the ADO > ConnectionPtr->Execute command does not report failure. It returns S_OK. > > Is there some special way to get these failures reported from ADO? > > TIA > > Otis Bricker > > > > structure like this? Generally tables are static containers that aren't subject to change via an application, rather they are modified using DDL scripts that are locked away under some sort of version control. Tracy McKibben <tr***@realsqlguy.com> wrote in
Show quote news:ebTx#JCrGHA.148@TK2MSFTNGP04.phx.gbl: As I said, we are running scripts via ADO. It happens when we roll out a > Otis Bricker wrote: >> I am trying to run a script through ADO that changes the schema of a >> table. >> >> >> if not EXISTS ( SELECT * >> FROM dbo.syscolumns >> WHERE (name = N'owner') and id = (SELECT id from >> dbo.sysobjects >> >> where name = 'models')) >> begin >> >> -- several steps here omitted >> >> ALTER TABLE dbo.Accounts DROP COLUMN [id] >> >> -- More steps here >> >> End >> >> The problem is that this alter table command fails if we miss an >> index that uses id. THe script seems to end executino there but the >> call to the ADO ConnectionPtr->Execute command does not report >> failure. It returns S_OK. >> >> Is there some special way to get these failures reported from ADO? >> >> TIA >> >> Otis Bricker >> >> >> >> > > This seems sort of questionable to me - why are you altering a table > structure like this? Generally tables are static containers that > aren't subject to change via an application, rather they are modified > using DDL scripts that are locked away under some sort of version > control. > new version and need to modify the DB. We could make them run them from outside the application but it is easier from the users perspective to do it from the same spot they work and ADO was chosen to let us do several mods under the same transaction since some of the updates are done programatically with c++. The point is that the schema needs to change. We want to run the DDL scripts via ADO. When the 'alter table' in the middle of the begin/end fails, ADO does not provide notification of the error and continues running the rest of the script while sql-dmo and QA both seem to stop and report a failure. I'm just trying to figure out why they behave differently so that we can know when things are going wrong and provide info to fix it. Thanks agian. Otis B Otis Bricker <obric***@my-dejanews.com> wrote in
Show quote news:Xns98068F53E466obrickermydejanewsco@216.196.97.136: I guess this is just a mystery I will have to talk to MS about.> Tracy McKibben <tr***@realsqlguy.com> wrote in > news:ebTx#JCrGHA.148@TK2MSFTNGP04.phx.gbl: > >> Otis Bricker wrote: >>> I am trying to run a script through ADO that changes the schema of a >>> table. >>> >>> >>> if not EXISTS ( SELECT * >>> FROM dbo.syscolumns >>> WHERE (name = N'owner') and id = (SELECT id from >>> dbo.sysobjects >>> >>> where name = 'models')) >>> begin >>> >>> -- several steps here omitted >>> >>> ALTER TABLE dbo.Accounts DROP COLUMN [id] >>> >>> -- More steps here >>> >>> End >>> >>> The problem is that this alter table command fails if we miss an >>> index that uses id. THe script seems to end executino there but the >>> call to the ADO ConnectionPtr->Execute command does not report >>> failure. It returns S_OK. >>> >>> Is there some special way to get these failures reported from ADO? >>> >>> TIA >>> >>> Otis Bricker >>> >>> >>> >>> >> >> This seems sort of questionable to me - why are you altering a table >> structure like this? Generally tables are static containers that >> aren't subject to change via an application, rather they are modified >> using DDL scripts that are locked away under some sort of version >> control. >> > > As I said, we are running scripts via ADO. It happens when we roll out > a new version and need to modify the DB. We could make them run them > from outside the application but it is easier from the users > perspective to do it from the same spot they work and ADO was chosen > to let us do several mods under the same transaction since some of the > updates are done programatically with c++. > > The point is that the schema needs to change. We want to run the DDL > scripts via ADO. When the 'alter table' in the middle of the begin/end > fails, ADO does not provide notification of the error and continues > running the rest of the script while sql-dmo and QA both seem to stop > and report a failure. I'm just trying to figure out why they behave > differently so that we can know when things are going wrong and > provide info to fix it. > > Thanks agian. > Thanks anyway. Otis Bricker  |
|||||||||||||||||||||||
Other interesting topics