After performing an Audit we discovered that my
predicessor inadvertantly installed a SQL 2000 Enterprise
Edition instead of Standard.
This weekend I will be upgrading to a new Server and wish
to use this window to convert to the proper version of
SQL 2000.
It is my understanding that you can upgrade Standard to
Enterprise but cannot perform the reverse.
My question is, are the System databases the same between
versions.
I realize that master.spt_server_info.attribute_id Value
2 would need to be changed (DBMS_VER) as well as
attribute 500 (SYS_SPROC_VERSION)
Other than that does any body know why I cannot do the
following.
1. Backup all Databases on Original Server.
2. Modify the DBMS_VER. and SYS_SPROC_VERSION.
2. Stop All SQL Services on Original Services.
3. Copy All mdf and ldf to a network storage local.
4. Shut down the Original Server.
5. Remove the Original Server from Active Directory.
6. Boot up the New Server with the original IP Address
and Computer name.
7. Install SQL 2000 Standard.
8. Install SP 3a.
9. Stop All SQL Services.
10. Copy all mdfs and ldfs from the network storage to
the proper folder on the new Server.
11. Restart the SQL services.
Does anyone see any major problems with this?
I know I could just attach the the Database but then I
would have to re-write all jobs and create all users in
the master DB providing the SID and Password. SID are not
a problem, but some of the Passwords may be difficult to
come by. (Damn my predisesor!).Your scheme should work, from an architectural standpoint. And it most
probably will. But it is not supported, so give yourself time to verify that
everything seems OK after the switch. You need to make sure that you have
the same directory structure for the SQL Server database files.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"A Dubey" <adubey@.winstead.com> wrote in message
news:de1d01c40ae6$121701b0$a101280a@.phx.gbl...
> After performing an Audit we discovered that my
> predicessor inadvertantly installed a SQL 2000 Enterprise
> Edition instead of Standard.
> This weekend I will be upgrading to a new Server and wish
> to use this window to convert to the proper version of
> SQL 2000.
> It is my understanding that you can upgrade Standard to
> Enterprise but cannot perform the reverse.
> My question is, are the System databases the same between
> versions.
> I realize that master.spt_server_info.attribute_id Value
> 2 would need to be changed (DBMS_VER) as well as
> attribute 500 (SYS_SPROC_VERSION)
> Other than that does any body know why I cannot do the
> following.
> 1. Backup all Databases on Original Server.
> 2. Modify the DBMS_VER. and SYS_SPROC_VERSION.
> 2. Stop All SQL Services on Original Services.
> 3. Copy All mdf and ldf to a network storage local.
> 4. Shut down the Original Server.
> 5. Remove the Original Server from Active Directory.
> 6. Boot up the New Server with the original IP Address
> and Computer name.
> 7. Install SQL 2000 Standard.
> 8. Install SP 3a.
> 9. Stop All SQL Services.
> 10. Copy all mdfs and ldfs from the network storage to
> the proper folder on the new Server.
> 11. Restart the SQL services.
> Does anyone see any major problems with this?
> I know I could just attach the the Database but then I
> would have to re-write all jobs and create all users in
> the master DB providing the SID and Password. SID are not
> a problem, but some of the Passwords may be difficult to
> come by. (Damn my predisesor!).|||Thanks,
I felt like it would, Just wanted to get a little feed
back incase I was missing something.
AD
>--Original Message--
>Your scheme should work, from an architectural
standpoint. And it most
>probably will. But it is not supported, so give yourself
time to verify that
>everything seems OK after the switch. You need to make
sure that you have
>the same directory structure for the SQL Server database
files.
>--
>Tibor Karaszi, SQL Server MVP
>http://www.karaszi.com/sqlserver/default.asp
>
>"A Dubey" <adubey@.winstead.com> wrote in message
>news:de1d01c40ae6$121701b0$a101280a@.phx.gbl...
Enterprise
wish
between
Value
not
to
>
>.
>
Showing posts with label instead. Show all posts
Showing posts with label instead. Show all posts
Monday, March 26, 2012
enterprise to standard
dear all,
if one has purchased enterprise edition of sql server, could he install the standard version instead of the enterprise one without violating software license?
regards
My suggestion would be to contact the vendor that you purchased the licenese through and check with them.
Thanks,
Sam Lester (MSFT)
enterprise to standard
dear all,
if one has purchased enterprise edition of sql server, could he install the standard version instead of the enterprise one without violating software license?
regards
My suggestion would be to contact the vendor that you purchased the licenese through and check with them.
Thanks,
Sam Lester (MSFT)
Wednesday, March 21, 2012
Enterprise Manager vs. INSTEAD OF triggers?
Hello all, i seem to have run into something weird...
I have a view which joins several tables (one main, and several relational
lookups). The view is simple-updateable, but i overrode this with an INSTEAD
OF UPDATE trigger to prevent people from changing the key fields, or the
lookup values. This works fine from Query Analyzer, or Access. If i try to
update one of the other fields, it simply doesnt take but the fields which
do get handled by the trigger do... all works fine.
However, if i open the view in Ent. Mgr. and type in changes to one of the
"non-updatable" fields, it actually updates it. It appears to be that when
making changes to data through the Enterprise Manager data views, it
bypasses any triggers (or at least INSTEAD OF triggers).
Is this actually the case? It seems kind of screwey, but that would seem to
be borne out by my little experiments here.
Cheers,
- Arthur.
When you open a view and update the data from EM, the UPDATE statemenet is
issued directly to the table, not to the view. That's why the trigger is
bypassed.
"Arthur Dent" wrote:
> Hello all, i seem to have run into something weird...
> I have a view which joins several tables (one main, and several relational
> lookups). The view is simple-updateable, but i overrode this with an INSTEAD
> OF UPDATE trigger to prevent people from changing the key fields, or the
> lookup values. This works fine from Query Analyzer, or Access. If i try to
> update one of the other fields, it simply doesnt take but the fields which
> do get handled by the trigger do... all works fine.
> However, if i open the view in Ent. Mgr. and type in changes to one of the
> "non-updatable" fields, it actually updates it. It appears to be that when
> making changes to data through the Enterprise Manager data views, it
> bypasses any triggers (or at least INSTEAD OF triggers).
> Is this actually the case? It seems kind of screwey, but that would seem to
> be borne out by my little experiments here.
> Cheers,
> - Arthur.
>
>
|||Arthur Dent wrote:
> Hello all, i seem to have run into something weird...
> I have a view which joins several tables (one main, and several
> relational lookups). The view is simple-updateable, but i overrode
> this with an INSTEAD OF UPDATE trigger to prevent people from
> changing the key fields, or the lookup values. This works fine from
> Query Analyzer, or Access. If i try to update one of the other
> fields, it simply doesnt take but the fields which do get handled by
> the trigger do... all works fine.
> However, if i open the view in Ent. Mgr. and type in changes to one
> of the "non-updatable" fields, it actually updates it. It appears to
> be that when making changes to data through the Enterprise Manager
> data views, it bypasses any triggers (or at least INSTEAD OF
> triggers).
> Is this actually the case? It seems kind of screwey, but that would
> seem to be borne out by my little experiments here.
> Cheers,
> - Arthur.
I'm not seeing that behavior here. I created an instead of update
trigger on a table and SQL EM spits out an error when the trigger is
violated. Here's the code. What do you see when you change a date to
value greater than today?
create table test (col1 int identity not null, col2 datetime not null)
go
insert into test values (getdate())
insert into test values (getdate() - 1)
insert into test values (getdate() - 2)
go
create trigger test_ioi on test
instead of update
as
begin
If Not Exists (Select * from inserted where col2 > getdate())
Update test
Set col2 = i.col2
From test, inserted i
Where test.col1 = i.col1
Else
RAISERROR ('Date provided is greater than today'' date. Update
failed.', 16, 1)
end
go
David Gugick
Imceda Software
www.imceda.com
|||My trigger is on a VIEW, not on a table. Jack answered above though, and
apparently explained why i get this behaviour.
In EM, when you open a view, its not actually opening the view, but the
underlying tables, only using the view definition. So triggers on the view
DO get bypassed.
|||Just an FYI, there is not such thing as "opening" a table or a view. EM does SELECT against the view
but issue the UPDATE/INSERT/DELETE against the table. Check out the WITH VIEW_METADATA option when
you create the view to handle this.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Arthur Dent" <hitchhikersguideto-news@.yahoo.com> wrote in message
news:egeVjksOFHA.2468@.tk2msftngp13.phx.gbl...
> My trigger is on a VIEW, not on a table. Jack answered above though, and apparently explained why
> i get this behaviour.
> In EM, when you open a view, its not actually opening the view, but the underlying tables, only
> using the view definition. So triggers on the view DO get bypassed.
>
I have a view which joins several tables (one main, and several relational
lookups). The view is simple-updateable, but i overrode this with an INSTEAD
OF UPDATE trigger to prevent people from changing the key fields, or the
lookup values. This works fine from Query Analyzer, or Access. If i try to
update one of the other fields, it simply doesnt take but the fields which
do get handled by the trigger do... all works fine.
However, if i open the view in Ent. Mgr. and type in changes to one of the
"non-updatable" fields, it actually updates it. It appears to be that when
making changes to data through the Enterprise Manager data views, it
bypasses any triggers (or at least INSTEAD OF triggers).
Is this actually the case? It seems kind of screwey, but that would seem to
be borne out by my little experiments here.
Cheers,
- Arthur.
When you open a view and update the data from EM, the UPDATE statemenet is
issued directly to the table, not to the view. That's why the trigger is
bypassed.
"Arthur Dent" wrote:
> Hello all, i seem to have run into something weird...
> I have a view which joins several tables (one main, and several relational
> lookups). The view is simple-updateable, but i overrode this with an INSTEAD
> OF UPDATE trigger to prevent people from changing the key fields, or the
> lookup values. This works fine from Query Analyzer, or Access. If i try to
> update one of the other fields, it simply doesnt take but the fields which
> do get handled by the trigger do... all works fine.
> However, if i open the view in Ent. Mgr. and type in changes to one of the
> "non-updatable" fields, it actually updates it. It appears to be that when
> making changes to data through the Enterprise Manager data views, it
> bypasses any triggers (or at least INSTEAD OF triggers).
> Is this actually the case? It seems kind of screwey, but that would seem to
> be borne out by my little experiments here.
> Cheers,
> - Arthur.
>
>
|||Arthur Dent wrote:
> Hello all, i seem to have run into something weird...
> I have a view which joins several tables (one main, and several
> relational lookups). The view is simple-updateable, but i overrode
> this with an INSTEAD OF UPDATE trigger to prevent people from
> changing the key fields, or the lookup values. This works fine from
> Query Analyzer, or Access. If i try to update one of the other
> fields, it simply doesnt take but the fields which do get handled by
> the trigger do... all works fine.
> However, if i open the view in Ent. Mgr. and type in changes to one
> of the "non-updatable" fields, it actually updates it. It appears to
> be that when making changes to data through the Enterprise Manager
> data views, it bypasses any triggers (or at least INSTEAD OF
> triggers).
> Is this actually the case? It seems kind of screwey, but that would
> seem to be borne out by my little experiments here.
> Cheers,
> - Arthur.
I'm not seeing that behavior here. I created an instead of update
trigger on a table and SQL EM spits out an error when the trigger is
violated. Here's the code. What do you see when you change a date to
value greater than today?
create table test (col1 int identity not null, col2 datetime not null)
go
insert into test values (getdate())
insert into test values (getdate() - 1)
insert into test values (getdate() - 2)
go
create trigger test_ioi on test
instead of update
as
begin
If Not Exists (Select * from inserted where col2 > getdate())
Update test
Set col2 = i.col2
From test, inserted i
Where test.col1 = i.col1
Else
RAISERROR ('Date provided is greater than today'' date. Update
failed.', 16, 1)
end
go
David Gugick
Imceda Software
www.imceda.com
|||My trigger is on a VIEW, not on a table. Jack answered above though, and
apparently explained why i get this behaviour.
In EM, when you open a view, its not actually opening the view, but the
underlying tables, only using the view definition. So triggers on the view
DO get bypassed.
|||Just an FYI, there is not such thing as "opening" a table or a view. EM does SELECT against the view
but issue the UPDATE/INSERT/DELETE against the table. Check out the WITH VIEW_METADATA option when
you create the view to handle this.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Arthur Dent" <hitchhikersguideto-news@.yahoo.com> wrote in message
news:egeVjksOFHA.2468@.tk2msftngp13.phx.gbl...
> My trigger is on a VIEW, not on a table. Jack answered above though, and apparently explained why
> i get this behaviour.
> In EM, when you open a view, its not actually opening the view, but the underlying tables, only
> using the view definition. So triggers on the view DO get bypassed.
>
Subscribe to:
Posts (Atom)