Current Environment:
SQL 2000 SP4 EE on Windows 2003 SP1
I need some suggestion on some of the currently available options for
reporting.
We have a transactional database where lots of transactions come throughout
the day. Some of the tables can have over 200 k records added. We need to
aggregate data on another server for reporting purposes and currently all
this is done via DTS jobs which do lots of locking and time consuming.
Since we are looking into re-architecting this solution and go away from
DTS, I am looking for various options that we can set up in test environment
and see which one supercedes over another one. Also, should I look into SQL
2005 or stay with SQL 2000 only.
Please advice.
Thanks in Advance."Mark" <Mark@.discussions.microsoft.com> wrote in message
news:8F1E6BD8-A36D-4D3E-8799-C67DF4F19D9D@.microsoft.com...
> Current Environment:
> SQL 2000 SP4 EE on Windows 2003 SP1
> I need some suggestion on some of the currently available options for
> reporting.
> We have a transactional database where lots of transactions come
> throughout
> the day. Some of the tables can have over 200 k records added. We need to
> aggregate data on another server for reporting purposes and currently all
> this is done via DTS jobs which do lots of locking and time consuming.
> Since we are looking into re-architecting this solution and go away from
> DTS, I am looking for various options that we can set up in test
> environment
> and see which one supercedes over another one. Also, should I look into
> SQL
> 2005 or stay with SQL 2000 only.
> Please advice.
> Thanks in Advance.
If the jobs are doing that much locking, then I would probably look at
rearchitecting the jobs themselves. Take advantage of the WITH (NOLOCK)
hints where appropriate etc.
Having your reporting done on the live data with the same aggregations that
your DTS jobs are doing doesn't seem like a particularly good idea to me.
Your performance will be better on the aggregated data already stored in the
reporting database server.
Just my .02
Rick Sawtell
MCT, MCSD, MCDBAsql
Showing posts with label current. Show all posts
Showing posts with label current. Show all posts
Tuesday, March 27, 2012
Sunday, March 25, 2012
Best Practices: Should other (unrelated) applications be installed on a SQL server?
I was taught long ago that database servers should be database servers
and nothing more. I have been asked by my current employer to install
a new application on our SQL server because "we aren't using all of
it." In other words, they feel the server is under-utilized and want
to run other applications on it. I told them this was a bad idea and
that we should identify another server for the installation. That was
rejected and I've been challenged to "prove" that best practices are
to avoid loading unrelated applications on a database server.
Can anyone point me to a statement from Microsoft or some DB authority
that says as much? I have located dozens of bloggers who agree with
me but I can't really cite "CyberDawg420" as a reference when making
my argument. Any help at all is greatly appreciated!
You seem to be trying to "prove" common sense.
How about this. Don't share unless there is absolutely no choice.
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP
<jimguytrucker@.yahoo.com> wrote in message
news:1194452329.877280.250570@.v3g2000hsg.googlegro ups.com...
>I was taught long ago that database servers should be database servers
> and nothing more. I have been asked by my current employer to install
> a new application on our SQL server because "we aren't using all of
> it." In other words, they feel the server is under-utilized and want
> to run other applications on it. I told them this was a bad idea and
> that we should identify another server for the installation. That was
> rejected and I've been challenged to "prove" that best practices are
> to avoid loading unrelated applications on a database server.
> Can anyone point me to a statement from Microsoft or some DB authority
> that says as much? I have located dozens of bloggers who agree with
> me but I can't really cite "CyberDawg420" as a reference when making
> my argument. Any help at all is greatly appreciated!
>
|||On Nov 7, 10:38 am, "Geoff N. Hiten" <SQLCrafts...@.gmail.com> wrote:
> You seem to be trying to "prove" common sense.
> How about this. Don't share unless there is absolutely no choice.
> --
> Geoff N. Hiten
> Senior SQL Infrastructure Consultant
> Microsoft SQL Server MVP
> <jimguytruc...@.yahoo.com> wrote in message
> news:1194452329.877280.250570@.v3g2000hsg.googlegro ups.com...
>
>
> - Show quoted text -
You are spot on with the "common sense" comment. I'm frustrated
because it is obvious to me but they want "evidence." The only way to
PROVE I'm right is to do what they ask, slow down the SQL server, and
create numerous headaches. I would be willing to do this to make my
point but I'm the one who would have to clean up the aftermath.
and nothing more. I have been asked by my current employer to install
a new application on our SQL server because "we aren't using all of
it." In other words, they feel the server is under-utilized and want
to run other applications on it. I told them this was a bad idea and
that we should identify another server for the installation. That was
rejected and I've been challenged to "prove" that best practices are
to avoid loading unrelated applications on a database server.
Can anyone point me to a statement from Microsoft or some DB authority
that says as much? I have located dozens of bloggers who agree with
me but I can't really cite "CyberDawg420" as a reference when making
my argument. Any help at all is greatly appreciated!
You seem to be trying to "prove" common sense.
How about this. Don't share unless there is absolutely no choice.
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP
<jimguytrucker@.yahoo.com> wrote in message
news:1194452329.877280.250570@.v3g2000hsg.googlegro ups.com...
>I was taught long ago that database servers should be database servers
> and nothing more. I have been asked by my current employer to install
> a new application on our SQL server because "we aren't using all of
> it." In other words, they feel the server is under-utilized and want
> to run other applications on it. I told them this was a bad idea and
> that we should identify another server for the installation. That was
> rejected and I've been challenged to "prove" that best practices are
> to avoid loading unrelated applications on a database server.
> Can anyone point me to a statement from Microsoft or some DB authority
> that says as much? I have located dozens of bloggers who agree with
> me but I can't really cite "CyberDawg420" as a reference when making
> my argument. Any help at all is greatly appreciated!
>
|||On Nov 7, 10:38 am, "Geoff N. Hiten" <SQLCrafts...@.gmail.com> wrote:
> You seem to be trying to "prove" common sense.
> How about this. Don't share unless there is absolutely no choice.
> --
> Geoff N. Hiten
> Senior SQL Infrastructure Consultant
> Microsoft SQL Server MVP
> <jimguytruc...@.yahoo.com> wrote in message
> news:1194452329.877280.250570@.v3g2000hsg.googlegro ups.com...
>
>
> - Show quoted text -
You are spot on with the "common sense" comment. I'm frustrated
because it is obvious to me but they want "evidence." The only way to
PROVE I'm right is to do what they ask, slow down the SQL server, and
create numerous headaches. I would be willing to do this to make my
point but I'm the one who would have to clean up the aftermath.
Best Practices: Should other (unrelated) applications be installed on a SQL server?
I was taught long ago that database servers should be database servers
and nothing more. I have been asked by my current employer to install
a new application on our SQL server because "we aren't using all of
it." In other words, they feel the server is under-utilized and want
to run other applications on it. I told them this was a bad idea and
that we should identify another server for the installation. That was
rejected and I've been challenged to "prove" that best practices are
to avoid loading unrelated applications on a database server.
Can anyone point me to a statement from Microsoft or some DB authority
that says as much? I have located dozens of bloggers who agree with
me but I can't really cite "CyberDawg420" as a reference when making
my argument. Any help at all is greatly appreciated!You seem to be trying to "prove" common sense.
How about this. Don't share unless there is absolutely no choice.
--
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP
<jimguytrucker@.yahoo.com> wrote in message
news:1194452329.877280.250570@.v3g2000hsg.googlegroups.com...
>I was taught long ago that database servers should be database servers
> and nothing more. I have been asked by my current employer to install
> a new application on our SQL server because "we aren't using all of
> it." In other words, they feel the server is under-utilized and want
> to run other applications on it. I told them this was a bad idea and
> that we should identify another server for the installation. That was
> rejected and I've been challenged to "prove" that best practices are
> to avoid loading unrelated applications on a database server.
> Can anyone point me to a statement from Microsoft or some DB authority
> that says as much? I have located dozens of bloggers who agree with
> me but I can't really cite "CyberDawg420" as a reference when making
> my argument. Any help at all is greatly appreciated!
>|||On Nov 7, 10:38 am, "Geoff N. Hiten" <SQLCrafts...@.gmail.com> wrote:
> You seem to be trying to "prove" common sense.
> How about this. Don't share unless there is absolutely no choice.
> --
> Geoff N. Hiten
> Senior SQL Infrastructure Consultant
> Microsoft SQL Server MVP
> <jimguytruc...@.yahoo.com> wrote in message
> news:1194452329.877280.250570@.v3g2000hsg.googlegroups.com...
>
> >I was taught long ago that database servers should be database servers
> > and nothing more. I have been asked by my current employer to install
> > a new application on our SQL server because "we aren't using all of
> > it." In other words, they feel the server is under-utilized and want
> > to run other applications on it. I told them this was a bad idea and
> > that we should identify another server for the installation. That was
> > rejected and I've been challenged to "prove" that best practices are
> > to avoid loading unrelated applications on a database server.
> > Can anyone point me to a statement from Microsoft or some DB authority
> > that says as much? I have located dozens of bloggers who agree with
> > me but I can't really cite "CyberDawg420" as a reference when making
> > my argument. Any help at all is greatly appreciated!- Hide quoted text -
> - Show quoted text -
You are spot on with the "common sense" comment. I'm frustrated
because it is obvious to me but they want "evidence." The only way to
PROVE I'm right is to do what they ask, slow down the SQL server, and
create numerous headaches. I would be willing to do this to make my
point but I'm the one who would have to clean up the aftermath.
and nothing more. I have been asked by my current employer to install
a new application on our SQL server because "we aren't using all of
it." In other words, they feel the server is under-utilized and want
to run other applications on it. I told them this was a bad idea and
that we should identify another server for the installation. That was
rejected and I've been challenged to "prove" that best practices are
to avoid loading unrelated applications on a database server.
Can anyone point me to a statement from Microsoft or some DB authority
that says as much? I have located dozens of bloggers who agree with
me but I can't really cite "CyberDawg420" as a reference when making
my argument. Any help at all is greatly appreciated!You seem to be trying to "prove" common sense.
How about this. Don't share unless there is absolutely no choice.
--
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP
<jimguytrucker@.yahoo.com> wrote in message
news:1194452329.877280.250570@.v3g2000hsg.googlegroups.com...
>I was taught long ago that database servers should be database servers
> and nothing more. I have been asked by my current employer to install
> a new application on our SQL server because "we aren't using all of
> it." In other words, they feel the server is under-utilized and want
> to run other applications on it. I told them this was a bad idea and
> that we should identify another server for the installation. That was
> rejected and I've been challenged to "prove" that best practices are
> to avoid loading unrelated applications on a database server.
> Can anyone point me to a statement from Microsoft or some DB authority
> that says as much? I have located dozens of bloggers who agree with
> me but I can't really cite "CyberDawg420" as a reference when making
> my argument. Any help at all is greatly appreciated!
>|||On Nov 7, 10:38 am, "Geoff N. Hiten" <SQLCrafts...@.gmail.com> wrote:
> You seem to be trying to "prove" common sense.
> How about this. Don't share unless there is absolutely no choice.
> --
> Geoff N. Hiten
> Senior SQL Infrastructure Consultant
> Microsoft SQL Server MVP
> <jimguytruc...@.yahoo.com> wrote in message
> news:1194452329.877280.250570@.v3g2000hsg.googlegroups.com...
>
> >I was taught long ago that database servers should be database servers
> > and nothing more. I have been asked by my current employer to install
> > a new application on our SQL server because "we aren't using all of
> > it." In other words, they feel the server is under-utilized and want
> > to run other applications on it. I told them this was a bad idea and
> > that we should identify another server for the installation. That was
> > rejected and I've been challenged to "prove" that best practices are
> > to avoid loading unrelated applications on a database server.
> > Can anyone point me to a statement from Microsoft or some DB authority
> > that says as much? I have located dozens of bloggers who agree with
> > me but I can't really cite "CyberDawg420" as a reference when making
> > my argument. Any help at all is greatly appreciated!- Hide quoted text -
> - Show quoted text -
You are spot on with the "common sense" comment. I'm frustrated
because it is obvious to me but they want "evidence." The only way to
PROVE I'm right is to do what they ask, slow down the SQL server, and
create numerous headaches. I would be willing to do this to make my
point but I'm the one who would have to clean up the aftermath.
Thursday, March 22, 2012
Best Practices: Should other (unrelated) applications be installed on a SQL server?
I was taught long ago that database servers should be database servers
and nothing more. I have been asked by my current employer to install
a new application on our SQL server because "we aren't using all of
it." In other words, they feel the server is under-utilized and want
to run other applications on it. I told them this was a bad idea and
that we should identify another server for the installation. That was
rejected and I've been challenged to "prove" that best practices are
to avoid loading unrelated applications on a database server.
Can anyone point me to a statement from Microsoft or some DB authority
that says as much? I have located dozens of bloggers who agree with
me but I can't really cite "CyberDawg420" as a reference when making
my argument. Any help at all is greatly appreciated!You seem to be trying to "prove" common sense.
How about this. Don't share unless there is absolutely no choice.
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP
<jimguytrucker@.yahoo.com> wrote in message
news:1194452329.877280.250570@.v3g2000hsg.googlegroups.com...
>I was taught long ago that database servers should be database servers
> and nothing more. I have been asked by my current employer to install
> a new application on our SQL server because "we aren't using all of
> it." In other words, they feel the server is under-utilized and want
> to run other applications on it. I told them this was a bad idea and
> that we should identify another server for the installation. That was
> rejected and I've been challenged to "prove" that best practices are
> to avoid loading unrelated applications on a database server.
> Can anyone point me to a statement from Microsoft or some DB authority
> that says as much? I have located dozens of bloggers who agree with
> me but I can't really cite "CyberDawg420" as a reference when making
> my argument. Any help at all is greatly appreciated!
>sql
and nothing more. I have been asked by my current employer to install
a new application on our SQL server because "we aren't using all of
it." In other words, they feel the server is under-utilized and want
to run other applications on it. I told them this was a bad idea and
that we should identify another server for the installation. That was
rejected and I've been challenged to "prove" that best practices are
to avoid loading unrelated applications on a database server.
Can anyone point me to a statement from Microsoft or some DB authority
that says as much? I have located dozens of bloggers who agree with
me but I can't really cite "CyberDawg420" as a reference when making
my argument. Any help at all is greatly appreciated!You seem to be trying to "prove" common sense.
How about this. Don't share unless there is absolutely no choice.
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP
<jimguytrucker@.yahoo.com> wrote in message
news:1194452329.877280.250570@.v3g2000hsg.googlegroups.com...
>I was taught long ago that database servers should be database servers
> and nothing more. I have been asked by my current employer to install
> a new application on our SQL server because "we aren't using all of
> it." In other words, they feel the server is under-utilized and want
> to run other applications on it. I told them this was a bad idea and
> that we should identify another server for the installation. That was
> rejected and I've been challenged to "prove" that best practices are
> to avoid loading unrelated applications on a database server.
> Can anyone point me to a statement from Microsoft or some DB authority
> that says as much? I have located dozens of bloggers who agree with
> me but I can't really cite "CyberDawg420" as a reference when making
> my argument. Any help at all is greatly appreciated!
>sql
Tuesday, March 20, 2012
Best Practices Analyzer Installation Problem
For my classes, I build a machine with all the necessary tools, including the current version of the Best Practices Analyzer. We then create a Norton Ghost image of this machine. The ghost image is restored to each classroom machine. I run a program to change the machine name, its IP address and randomize the machine's SID. Then I join the machine to the domain. All the installed software is available to the logged in user (Office, SQL Server 2000, SQL Server 2005, etc.) except BPA. Note that when I built the machine that was the source of the Ghost image, I logged in as each user and set up Outlook Express profiles and Office Profiles. When any user other than the user who installed BPA tries to run it, it issues a message that BPA must be installed. If I change the executable to run as the user who installed it, it works. But I can't find any way to make this change "generic". For example, as a local administrator, I install BPA. Then I log in to Windows as User15. I change BPA to run as administrator. It works for User15. But if I subsequently log in on that machine as User16, BPA still gives the "must be installed" message.
All of the student logins are local administrators, and the Administrators group has full control access to the BPA executable.
How do I fix this?
Thanks,
Sharon
Put the shortcut for BPA in the everyone document folder?
It sounds like a chain of custody control issue, if you log in as user16, you can not use a program installed by user15? If the program requires admin priv, then all users of the program must be admin?
This of course assumes that you really are the admin on the machine and not a "virtual admin" associated with some sys protection programs out there (and viruses of course)?
Have fun :)
Best Practices Analyzer Installation Problem
For my classes, I build a machine with all the necessary tools, including the current version of the Best Practices Analyzer. We then create a Norton Ghost image of this machine. The ghost image is restored to each classroom machine. I run a program to change the machine name, its IP address and randomize the machine's SID. Then I join the machine to the domain. All the installed software is available to the logged in user (Office, SQL Server 2000, SQL Server 2005, etc.) except BPA. Note that when I built the machine that was the source of the Ghost image, I logged in as each user and set up Outlook Express profiles and Office Profiles. When any user other than the user who installed BPA tries to run it, it issues a message that BPA must be installed. If I change the executable to run as the user who installed it, it works. But I can't find any way to make this change "generic". For example, as a local administrator, I install BPA. Then I log in to Windows as User15. I change BPA to run as administrator. It works for User15. But if I subsequently log in on that machine as User16, BPA still gives the "must be installed" message.
All of the student logins are local administrators, and the Administrators group has full control access to the BPA executable.
How do I fix this?
Thanks,
Sharon
Put the shortcut for BPA in the everyone document folder?
It sounds like a chain of custody control issue, if you log in as user16, you can not use a program installed by user15? If the program requires admin priv, then all users of the program must be admin?
This of course assumes that you really are the admin on the machine and not a "virtual admin" associated with some sys protection programs out there (and viruses of course)?
Have fun :)
Monday, March 19, 2012
best practice retrieveing current identity value
HI all,
I have a claim table. An insert trigger, in that insert trigger I want to
retrieve the current identity value of that insert, to be used elswhere
which is best scope_identity(), ident_current(), or @.@.identity
Thanks
RobertRobert,
All three will (in theory) work, and each has it's own values for a given
situation.
I tend to use @.@.identity, though, as BoL explains, this is not limited to
the current scope, and so they would suggest using SCOPE_IDENTITY which woul
d
be more exacting.
Hope this assists,
Tony
"Robert Bravery" wrote:
> HI all,
> I have a claim table. An insert trigger, in that insert trigger I want to
> retrieve the current identity value of that insert, to be used elswhere
> which is best scope_identity(), ident_current(), or @.@.identity
> Thanks
> Robert
>
>|||Robert Bravery wrote:
> HI all,
> I have a claim table. An insert trigger, in that insert trigger I want to
> retrieve the current identity value of that insert, to be used elswhere
> which is best scope_identity(), ident_current(), or @.@.identity
> Thanks
> Robert
Did you read about the differences between those functions in Books
Online? Either may be appropriate depending on requirements.
BUT - a big but - they are all unlikely to be useful in a trigger.
That's because well-written trigger code should always assume that more
than one row may be updated in the table that invokes the trigger.
Triggers fire once per statement, NOT once per row, so usually in a
trigger if you want to retrieve the inserted IDENTITY values you do so
by referencing the virtual table called INSERTED. That table could
contain 0,1,2 or any number of rows.
The IDENTITY functions would probably only be useful in a trigger if
your trigger contained a single row INSERT to another table regardless
of how many rows were updated by the statement that prompted the
trigger. In that case you would probably use SCOPE_IDENTITY.
Hope this helps.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||David,
Interesting point. Where would that leave us when using either
SCOPE_IDENTITY or @.@.Identity from a SProc? I was under the belief that the
correct identity was always returned from that thread used. Would you say
then that a trigger could be less precise than a SProc for retrieving the
correct Identity for a given inert transaction?
Any further insight would be useful,
Thanks,
Tony
"David Portas" wrote:
> Robert Bravery wrote:
> Did you read about the differences between those functions in Books
> Online? Either may be appropriate depending on requirements.
> BUT - a big but - they are all unlikely to be useful in a trigger.
> That's because well-written trigger code should always assume that more
> than one row may be updated in the table that invokes the trigger.
> Triggers fire once per statement, NOT once per row, so usually in a
> trigger if you want to retrieve the inserted IDENTITY values you do so
> by referencing the virtual table called INSERTED. That table could
> contain 0,1,2 or any number of rows.
> The IDENTITY functions would probably only be useful in a trigger if
> your trigger contained a single row INSERT to another table regardless
> of how many rows were updated by the statement that prompted the
> trigger. In that case you would probably use SCOPE_IDENTITY.
> Hope this helps.
> --
> David Portas, SQL Server MVP
> Whenever possible please post enough code to reproduce your problem.
> Including CREATE TABLE and INSERT statements usually helps.
> State what version of SQL Server you are using and specify the content
> of any error messages.
> SQL Server Books Online:
> http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
> --
>|||Tony Scott wrote:
> David,
> Interesting point. Where would that leave us when using either
> SCOPE_IDENTITY or @.@.Identity from a SProc? I was under the belief that the
> correct identity was always returned from that thread used. Would you say
> then that a trigger could be less precise than a SProc for retrieving the
> correct Identity for a given inert transaction?
> Any further insight would be useful,
> Thanks,
> Tony
>
SCOPE_IDENTITY does always have local scope but so does the INSERTED
virtual table in a trigger. In that respect a trigger is no less
precise in the way IDENTITY is retrieved - it's just that you have to
allow for multiple-row inserts. Example:
CREATE TABLE T1 (x INTEGER NOT NULL IDENTITY PRIMARY KEY, z INTEGER NOT
NULL UNIQUE)
GO
CREATE TRIGGER trg ON T1 FOR INSERT
AS
SELECT SCOPE_IDENTITY() AS [scope_identity] ;
SELECT @.@.IDENTITY AS [@.@.identity] ;
SELECT IDENT_CURRENT('T1') AS [ident_current] ;
GO
INSERT INTO T1 (z)
SELECT 1 UNION ALL
SELECT 2 ;
scope_identity
---
NULL
(1 row(s) affected)
@.@.identity
---
2
(1 row(s) affected)
ident_current
---
2
(1 row(s) affected)
The first result (NULL) is wrong because SCOPE_IDENTITY has local scope
so it doesn't see the INSERT at all.
The second is wrong because although it returns one of the IDENTITY
values there were actually two rows inserted. We can't predict the row
for which the IDENTITY will be returned - it will just be the highest
numbered IDENTITY value. This isn't good in a trigger because we can
only use this method to reference a single row and triggers should
always assume multiple rows may be updated.
The third result may be wrong if other connections also update the
table because IDENT_CURRENT is scoped to the table and not to the
session.
The reliable method uses the INSERTED table:
CREATE TRIGGER trg ON T1 FOR INSERT
AS
SELECT x FROM inserted ;
GO
If your procs insert multiple rows you also need to think about the
same issue in procs when you need the IDENTITY value. Don't assume the
values inserted will be contiguous with the value returned by
SCOPE_IDENTITY. There are at least some conditions where they may not
be.
In SQL Server 2005 you can address things slightly differently using
the OUPUT clause of the INSERT, UPDATE and DELETE statements. These
could eliminate the need for some triggers.
In SQL Server 2000 you should also be able to retrieve multiple
IDENTITY values using an alternate key of the table. There should
always be another candidate key. If you don't have such a key then you
have a significant design flaw which you should fix.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||David,
Thank you for an excellent answer, very informative.
Tony
"David Portas" wrote:
> Tony Scott wrote:
> SCOPE_IDENTITY does always have local scope but so does the INSERTED
> virtual table in a trigger. In that respect a trigger is no less
> precise in the way IDENTITY is retrieved - it's just that you have to
> allow for multiple-row inserts. Example:
> CREATE TABLE T1 (x INTEGER NOT NULL IDENTITY PRIMARY KEY, z INTEGER NOT
> NULL UNIQUE)
> GO
> CREATE TRIGGER trg ON T1 FOR INSERT
> AS
> SELECT SCOPE_IDENTITY() AS [scope_identity] ;
> SELECT @.@.IDENTITY AS [@.@.identity] ;
> SELECT IDENT_CURRENT('T1') AS [ident_current] ;
> GO
> INSERT INTO T1 (z)
> SELECT 1 UNION ALL
> SELECT 2 ;
> scope_identity
> ---
> NULL
> (1 row(s) affected)
> @.@.identity
> ---
> 2
> (1 row(s) affected)
> ident_current
> ---
> 2
> (1 row(s) affected)
>
> The first result (NULL) is wrong because SCOPE_IDENTITY has local scope
> so it doesn't see the INSERT at all.
> The second is wrong because although it returns one of the IDENTITY
> values there were actually two rows inserted. We can't predict the row
> for which the IDENTITY will be returned - it will just be the highest
> numbered IDENTITY value. This isn't good in a trigger because we can
> only use this method to reference a single row and triggers should
> always assume multiple rows may be updated.
> The third result may be wrong if other connections also update the
> table because IDENT_CURRENT is scoped to the table and not to the
> session.
> The reliable method uses the INSERTED table:
> CREATE TRIGGER trg ON T1 FOR INSERT
> AS
> SELECT x FROM inserted ;
> GO
> If your procs insert multiple rows you also need to think about the
> same issue in procs when you need the IDENTITY value. Don't assume the
> values inserted will be contiguous with the value returned by
> SCOPE_IDENTITY. There are at least some conditions where they may not
> be.
> In SQL Server 2005 you can address things slightly differently using
> the OUPUT clause of the INSERT, UPDATE and DELETE statements. These
> could eliminate the need for some triggers.
> In SQL Server 2000 you should also be able to retrieve multiple
> IDENTITY values using an alternate key of the table. There should
> always be another candidate key. If you don't have such a key then you
> have a significant design flaw which you should fix.
> --
> David Portas, SQL Server MVP
> Whenever possible please post enough code to reproduce your problem.
> Including CREATE TABLE and INSERT statements usually helps.
> State what version of SQL Server you are using and specify the content
> of any error messages.
> SQL Server Books Online:
> http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
> --
>|||Hi,
Thanks for the reply David.
> Did you read about the differences between those functions in Books
> Online? Either may be appropriate depending on requirements.
Yes I did. And I also got the idea that they all might be appropiate. But no
quite understanding the exact process of a insert trigger (as you explained)
I was
as to what was the more correct way
> BUT - a big but - they are all unlikely to be useful in a trigger.
> That's because well-written trigger code should always assume that more
> than one row may be updated in the table that invokes the trigger.
> Triggers fire once per statement, NOT once per row, so usually in a
> trigger if you want to retrieve the inserted IDENTITY values you do so
> by referencing the virtual table called INSERTED. That table could
> contain 0,1,2 or any number of rows.
At this point I am assumning a single row insert transaction. The table
involved is a claims table, needing a single input for each claim
as in:
INSERT INTO [RASRMIS].[dbo].[Claim]([divid], [dhid], [LayerID], [peril],
[cause], [resource], [fault], [DOL], [DREP])
VALUES(1812, 1237, 5, 1, 1, 1, 1, getdate()-1650, getdate())
Would this be considered as a single row insert, on a single statement,
single transaction
I then issued:
Select @.@.identity [@.@.Identity], SCOPE_IDENTITY() [SCOPE_IDENTITY()],
ident_current('claim') [ident_current()]
But got back all the same value.
But if I put the above statement into a trigger, I receive the dame values
from the @.@.identity and ident_current() functions. Scope_identity() returns
null. I would have thought that the insert trigger is within scope here
Hopefully I have explained correctly
Thankls
Robert|||Robert Bravery wrote:
> At this point I am assumning a single row insert transaction.
Why would you bother to assume that? It doesn't help you. It just means
the DBA will curse you one day when he needs to do some ad-hoc
maintenance... or integrate some external data... or the user needs an
enhancement to the application, or...
> The table
> involved is a claims table, needing a single input for each claim
> as in:
> INSERT INTO [RASRMIS].[dbo].[Claim]([divid], [dhid], [LayerID], [peril],
> [cause], [resource], [fault], [DOL], [DREP])
> VALUES(1812, 1237, 5, 1, 1, 1, 1, getdate()-1650, getdate())
> Would this be considered as a single row insert, on a single statement,
> single transaction
> I then issued:
> Select @.@.identity [@.@.Identity], SCOPE_IDENTITY() [SCOPE_IDENTITY()],
> ident_current('claim') [ident_current()]
> But got back all the same value.
> But if I put the above statement into a trigger, I receive the dame values
> from the @.@.identity and ident_current() functions. Scope_identity() return
s
> null. I would have thought that the insert trigger is within scope here
>
No. The trigger runs in its own scope.
The solution is:
SELECT id FROM inserted ;
"Inserted" is a virtual table only visible in triggers.
This isn't a good example because you don't usually want to return
results from triggers. The exact solution of course depends on what you
want to do with the IDENTITY value(s) after you retrieve them. For
example you can insert them to another table:
INSERT INTO other_table (id, ...)
SELECT id
FROM inserted ;
Hope this helps.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||Unless you're using an INSTEAD OF INSERT trigger, then you shouldn't rely on
the value returned by @.@.IDENTITY; under no circumstances should you rely on
the value returned by IDENT_CURRENT()--at least not for what you're looking
for. There can be more than one FOR or AFTER INSERT trigger on a table, and
any one of them could affect @.@.IDENTITY. IDENT_CURRENT() changes whenever
any INSERT occurs on any connection, so it could change between the time
that you read it and the time that you're ready to use it, or even worse: it
could change during whatever modification you're trying to make. In a FOR
or AFTER trigger, the only reliable ways to retrieve the generated IDENTITY
values is to use the inserted pseudotable, or to use another candidate key.
An INSTEAD OF trigger fires instead of the action specified, so new IDENTITY
values haven't yet been generated at the time that the inserted pseudotable
is populated. You can use SCOPE_IDENTITY() if you use a cursor to process
the contents of the inserted pseudotable, but I would recommend against it.
Using cursors in triggers is like publishing uncomplimentary caricatures of
Mohammed: you're bound to get burned. In an INSTEAD OF INSERT trigger,
you're best bet is to use another candidate key to obtain the IDENTITY
values.
"Robert Bravery" <me@.u.com> wrote in message
news:u07T2i9KGHA.1424@.TK2MSFTNGP12.phx.gbl...
> HI all,
> I have a claim table. An insert trigger, in that insert trigger I want to
> retrieve the current identity value of that insert, to be used elswhere
> which is best scope_identity(), ident_current(), or @.@.identity
> Thanks
> Robert
>
I have a claim table. An insert trigger, in that insert trigger I want to
retrieve the current identity value of that insert, to be used elswhere
which is best scope_identity(), ident_current(), or @.@.identity
Thanks
RobertRobert,
All three will (in theory) work, and each has it's own values for a given
situation.
I tend to use @.@.identity, though, as BoL explains, this is not limited to
the current scope, and so they would suggest using SCOPE_IDENTITY which woul
d
be more exacting.
Hope this assists,
Tony
"Robert Bravery" wrote:
> HI all,
> I have a claim table. An insert trigger, in that insert trigger I want to
> retrieve the current identity value of that insert, to be used elswhere
> which is best scope_identity(), ident_current(), or @.@.identity
> Thanks
> Robert
>
>|||Robert Bravery wrote:
> HI all,
> I have a claim table. An insert trigger, in that insert trigger I want to
> retrieve the current identity value of that insert, to be used elswhere
> which is best scope_identity(), ident_current(), or @.@.identity
> Thanks
> Robert
Did you read about the differences between those functions in Books
Online? Either may be appropriate depending on requirements.
BUT - a big but - they are all unlikely to be useful in a trigger.
That's because well-written trigger code should always assume that more
than one row may be updated in the table that invokes the trigger.
Triggers fire once per statement, NOT once per row, so usually in a
trigger if you want to retrieve the inserted IDENTITY values you do so
by referencing the virtual table called INSERTED. That table could
contain 0,1,2 or any number of rows.
The IDENTITY functions would probably only be useful in a trigger if
your trigger contained a single row INSERT to another table regardless
of how many rows were updated by the statement that prompted the
trigger. In that case you would probably use SCOPE_IDENTITY.
Hope this helps.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||David,
Interesting point. Where would that leave us when using either
SCOPE_IDENTITY or @.@.Identity from a SProc? I was under the belief that the
correct identity was always returned from that thread used. Would you say
then that a trigger could be less precise than a SProc for retrieving the
correct Identity for a given inert transaction?
Any further insight would be useful,
Thanks,
Tony
"David Portas" wrote:
> Robert Bravery wrote:
> Did you read about the differences between those functions in Books
> Online? Either may be appropriate depending on requirements.
> BUT - a big but - they are all unlikely to be useful in a trigger.
> That's because well-written trigger code should always assume that more
> than one row may be updated in the table that invokes the trigger.
> Triggers fire once per statement, NOT once per row, so usually in a
> trigger if you want to retrieve the inserted IDENTITY values you do so
> by referencing the virtual table called INSERTED. That table could
> contain 0,1,2 or any number of rows.
> The IDENTITY functions would probably only be useful in a trigger if
> your trigger contained a single row INSERT to another table regardless
> of how many rows were updated by the statement that prompted the
> trigger. In that case you would probably use SCOPE_IDENTITY.
> Hope this helps.
> --
> David Portas, SQL Server MVP
> Whenever possible please post enough code to reproduce your problem.
> Including CREATE TABLE and INSERT statements usually helps.
> State what version of SQL Server you are using and specify the content
> of any error messages.
> SQL Server Books Online:
> http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
> --
>|||Tony Scott wrote:
> David,
> Interesting point. Where would that leave us when using either
> SCOPE_IDENTITY or @.@.Identity from a SProc? I was under the belief that the
> correct identity was always returned from that thread used. Would you say
> then that a trigger could be less precise than a SProc for retrieving the
> correct Identity for a given inert transaction?
> Any further insight would be useful,
> Thanks,
> Tony
>
SCOPE_IDENTITY does always have local scope but so does the INSERTED
virtual table in a trigger. In that respect a trigger is no less
precise in the way IDENTITY is retrieved - it's just that you have to
allow for multiple-row inserts. Example:
CREATE TABLE T1 (x INTEGER NOT NULL IDENTITY PRIMARY KEY, z INTEGER NOT
NULL UNIQUE)
GO
CREATE TRIGGER trg ON T1 FOR INSERT
AS
SELECT SCOPE_IDENTITY() AS [scope_identity] ;
SELECT @.@.IDENTITY AS [@.@.identity] ;
SELECT IDENT_CURRENT('T1') AS [ident_current] ;
GO
INSERT INTO T1 (z)
SELECT 1 UNION ALL
SELECT 2 ;
scope_identity
---
NULL
(1 row(s) affected)
@.@.identity
---
2
(1 row(s) affected)
ident_current
---
2
(1 row(s) affected)
The first result (NULL) is wrong because SCOPE_IDENTITY has local scope
so it doesn't see the INSERT at all.
The second is wrong because although it returns one of the IDENTITY
values there were actually two rows inserted. We can't predict the row
for which the IDENTITY will be returned - it will just be the highest
numbered IDENTITY value. This isn't good in a trigger because we can
only use this method to reference a single row and triggers should
always assume multiple rows may be updated.
The third result may be wrong if other connections also update the
table because IDENT_CURRENT is scoped to the table and not to the
session.
The reliable method uses the INSERTED table:
CREATE TRIGGER trg ON T1 FOR INSERT
AS
SELECT x FROM inserted ;
GO
If your procs insert multiple rows you also need to think about the
same issue in procs when you need the IDENTITY value. Don't assume the
values inserted will be contiguous with the value returned by
SCOPE_IDENTITY. There are at least some conditions where they may not
be.
In SQL Server 2005 you can address things slightly differently using
the OUPUT clause of the INSERT, UPDATE and DELETE statements. These
could eliminate the need for some triggers.
In SQL Server 2000 you should also be able to retrieve multiple
IDENTITY values using an alternate key of the table. There should
always be another candidate key. If you don't have such a key then you
have a significant design flaw which you should fix.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||David,
Thank you for an excellent answer, very informative.
Tony
"David Portas" wrote:
> Tony Scott wrote:
> SCOPE_IDENTITY does always have local scope but so does the INSERTED
> virtual table in a trigger. In that respect a trigger is no less
> precise in the way IDENTITY is retrieved - it's just that you have to
> allow for multiple-row inserts. Example:
> CREATE TABLE T1 (x INTEGER NOT NULL IDENTITY PRIMARY KEY, z INTEGER NOT
> NULL UNIQUE)
> GO
> CREATE TRIGGER trg ON T1 FOR INSERT
> AS
> SELECT SCOPE_IDENTITY() AS [scope_identity] ;
> SELECT @.@.IDENTITY AS [@.@.identity] ;
> SELECT IDENT_CURRENT('T1') AS [ident_current] ;
> GO
> INSERT INTO T1 (z)
> SELECT 1 UNION ALL
> SELECT 2 ;
> scope_identity
> ---
> NULL
> (1 row(s) affected)
> @.@.identity
> ---
> 2
> (1 row(s) affected)
> ident_current
> ---
> 2
> (1 row(s) affected)
>
> The first result (NULL) is wrong because SCOPE_IDENTITY has local scope
> so it doesn't see the INSERT at all.
> The second is wrong because although it returns one of the IDENTITY
> values there were actually two rows inserted. We can't predict the row
> for which the IDENTITY will be returned - it will just be the highest
> numbered IDENTITY value. This isn't good in a trigger because we can
> only use this method to reference a single row and triggers should
> always assume multiple rows may be updated.
> The third result may be wrong if other connections also update the
> table because IDENT_CURRENT is scoped to the table and not to the
> session.
> The reliable method uses the INSERTED table:
> CREATE TRIGGER trg ON T1 FOR INSERT
> AS
> SELECT x FROM inserted ;
> GO
> If your procs insert multiple rows you also need to think about the
> same issue in procs when you need the IDENTITY value. Don't assume the
> values inserted will be contiguous with the value returned by
> SCOPE_IDENTITY. There are at least some conditions where they may not
> be.
> In SQL Server 2005 you can address things slightly differently using
> the OUPUT clause of the INSERT, UPDATE and DELETE statements. These
> could eliminate the need for some triggers.
> In SQL Server 2000 you should also be able to retrieve multiple
> IDENTITY values using an alternate key of the table. There should
> always be another candidate key. If you don't have such a key then you
> have a significant design flaw which you should fix.
> --
> David Portas, SQL Server MVP
> Whenever possible please post enough code to reproduce your problem.
> Including CREATE TABLE and INSERT statements usually helps.
> State what version of SQL Server you are using and specify the content
> of any error messages.
> SQL Server Books Online:
> http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
> --
>|||Hi,
Thanks for the reply David.
> Did you read about the differences between those functions in Books
> Online? Either may be appropriate depending on requirements.
Yes I did. And I also got the idea that they all might be appropiate. But no
quite understanding the exact process of a insert trigger (as you explained)
I was
as to what was the more correct way> BUT - a big but - they are all unlikely to be useful in a trigger.
> That's because well-written trigger code should always assume that more
> than one row may be updated in the table that invokes the trigger.
> Triggers fire once per statement, NOT once per row, so usually in a
> trigger if you want to retrieve the inserted IDENTITY values you do so
> by referencing the virtual table called INSERTED. That table could
> contain 0,1,2 or any number of rows.
At this point I am assumning a single row insert transaction. The table
involved is a claims table, needing a single input for each claim
as in:
INSERT INTO [RASRMIS].[dbo].[Claim]([divid], [dhid], [LayerID], [peril],
[cause], [resource], [fault], [DOL], [DREP])
VALUES(1812, 1237, 5, 1, 1, 1, 1, getdate()-1650, getdate())
Would this be considered as a single row insert, on a single statement,
single transaction
I then issued:
Select @.@.identity [@.@.Identity], SCOPE_IDENTITY() [SCOPE_IDENTITY()],
ident_current('claim') [ident_current()]
But got back all the same value.
But if I put the above statement into a trigger, I receive the dame values
from the @.@.identity and ident_current() functions. Scope_identity() returns
null. I would have thought that the insert trigger is within scope here
Hopefully I have explained correctly
Thankls
Robert|||Robert Bravery wrote:
> At this point I am assumning a single row insert transaction.
Why would you bother to assume that? It doesn't help you. It just means
the DBA will curse you one day when he needs to do some ad-hoc
maintenance... or integrate some external data... or the user needs an
enhancement to the application, or...
> The table
> involved is a claims table, needing a single input for each claim
> as in:
> INSERT INTO [RASRMIS].[dbo].[Claim]([divid], [dhid], [LayerID], [peril],
> [cause], [resource], [fault], [DOL], [DREP])
> VALUES(1812, 1237, 5, 1, 1, 1, 1, getdate()-1650, getdate())
> Would this be considered as a single row insert, on a single statement,
> single transaction
> I then issued:
> Select @.@.identity [@.@.Identity], SCOPE_IDENTITY() [SCOPE_IDENTITY()],
> ident_current('claim') [ident_current()]
> But got back all the same value.
> But if I put the above statement into a trigger, I receive the dame values
> from the @.@.identity and ident_current() functions. Scope_identity() return
s
> null. I would have thought that the insert trigger is within scope here
>
No. The trigger runs in its own scope.
The solution is:
SELECT id FROM inserted ;
"Inserted" is a virtual table only visible in triggers.
This isn't a good example because you don't usually want to return
results from triggers. The exact solution of course depends on what you
want to do with the IDENTITY value(s) after you retrieve them. For
example you can insert them to another table:
INSERT INTO other_table (id, ...)
SELECT id
FROM inserted ;
Hope this helps.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||Unless you're using an INSTEAD OF INSERT trigger, then you shouldn't rely on
the value returned by @.@.IDENTITY; under no circumstances should you rely on
the value returned by IDENT_CURRENT()--at least not for what you're looking
for. There can be more than one FOR or AFTER INSERT trigger on a table, and
any one of them could affect @.@.IDENTITY. IDENT_CURRENT() changes whenever
any INSERT occurs on any connection, so it could change between the time
that you read it and the time that you're ready to use it, or even worse: it
could change during whatever modification you're trying to make. In a FOR
or AFTER trigger, the only reliable ways to retrieve the generated IDENTITY
values is to use the inserted pseudotable, or to use another candidate key.
An INSTEAD OF trigger fires instead of the action specified, so new IDENTITY
values haven't yet been generated at the time that the inserted pseudotable
is populated. You can use SCOPE_IDENTITY() if you use a cursor to process
the contents of the inserted pseudotable, but I would recommend against it.
Using cursors in triggers is like publishing uncomplimentary caricatures of
Mohammed: you're bound to get burned. In an INSTEAD OF INSERT trigger,
you're best bet is to use another candidate key to obtain the IDENTITY
values.
"Robert Bravery" <me@.u.com> wrote in message
news:u07T2i9KGHA.1424@.TK2MSFTNGP12.phx.gbl...
> HI all,
> I have a claim table. An insert trigger, in that insert trigger I want to
> retrieve the current identity value of that insert, to be used elswhere
> which is best scope_identity(), ident_current(), or @.@.identity
> Thanks
> Robert
>
Saturday, February 25, 2012
best install scenario
In the current MSDN Universal disk set, there is a disk for Visual Studio
2005 (beta2) and a disk for SQL Server 2005. If you install VS2005 you get
the April CTP SQL server but without Server Management Studio. If you
install SQL Server 2005, you get VS2005 but without the normal code
development templates. What's the recommended install sequence to get both?
And after several install/uninstall sequences I seem to have lost start menu
links to VS.Net 2003. Can I have VS.Net 2003 and VS.Net 2005 on the same
machine?
tks
RonHi Ron,
Since SQL Server 2005 has not been public released yet, we will redirect
all SQL Server 2005 posts to the newsgroup below
http://communities.microsoft.com/newsgroups/default.asp?icp=sqlserver2005&sl
cid=us
Thanks so much for your understanding.
Sincerely yours,
Michael Cheng
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================This posting is provided "AS IS" with no warranties, and confers no rights.
2005 (beta2) and a disk for SQL Server 2005. If you install VS2005 you get
the April CTP SQL server but without Server Management Studio. If you
install SQL Server 2005, you get VS2005 but without the normal code
development templates. What's the recommended install sequence to get both?
And after several install/uninstall sequences I seem to have lost start menu
links to VS.Net 2003. Can I have VS.Net 2003 and VS.Net 2005 on the same
machine?
tks
RonHi Ron,
Since SQL Server 2005 has not been public released yet, we will redirect
all SQL Server 2005 posts to the newsgroup below
http://communities.microsoft.com/newsgroups/default.asp?icp=sqlserver2005&sl
cid=us
Thanks so much for your understanding.
Sincerely yours,
Michael Cheng
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================This posting is provided "AS IS" with no warranties, and confers no rights.
best install scenario
In the current MSDN Universal disk set, there is a disk for Visual Studio
2005 (beta2) and a disk for SQL Server 2005. If you install VS2005 you get
the April CTP SQL server but without Server Management Studio. If you
install SQL Server 2005, you get VS2005 but without the normal code
development templates. What's the recommended install sequence to get both?
And after several install/uninstall sequences I seem to have lost start menu
links to VS.Net 2003. Can I have VS.Net 2003 and VS.Net 2005 on the same
machine?
tks
RonHi Ron,
Since SQL Server 2005 has not been public released yet, we will redirect
all SQL Server 2005 posts to the newsgroup below
http://communities.microsoft.com/ne...qlserver2005&sl
cid=us
Thanks so much for your understanding.
Sincerely yours,
Michael Cheng
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
========================================
=============
This posting is provided "AS IS" with no warranties, and confers no rights.
2005 (beta2) and a disk for SQL Server 2005. If you install VS2005 you get
the April CTP SQL server but without Server Management Studio. If you
install SQL Server 2005, you get VS2005 but without the normal code
development templates. What's the recommended install sequence to get both?
And after several install/uninstall sequences I seem to have lost start menu
links to VS.Net 2003. Can I have VS.Net 2003 and VS.Net 2005 on the same
machine?
tks
RonHi Ron,
Since SQL Server 2005 has not been public released yet, we will redirect
all SQL Server 2005 posts to the newsgroup below
http://communities.microsoft.com/ne...qlserver2005&sl
cid=us
Thanks so much for your understanding.
Sincerely yours,
Michael Cheng
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
========================================
=============
This posting is provided "AS IS" with no warranties, and confers no rights.
best install scenario
In the current MSDN Universal disk set, there is a disk for Visual Studio
2005 (beta2) and a disk for SQL Server 2005. If you install VS2005 you get
the April CTP SQL server but without Server Management Studio. If you
install SQL Server 2005, you get VS2005 but without the normal code
development templates. What's the recommended install sequence to get both?
And after several install/uninstall sequences I seem to have lost start menu
links to VS.Net 2003. Can I have VS.Net 2003 and VS.Net 2005 on the same
machine?
tks
Ron
Hi Ron,
Since SQL Server 2005 has not been public released yet, we will redirect
all SQL Server 2005 posts to the newsgroup below
http://communities.microsoft.com/new...lserver2005&sl
cid=us
Thanks so much for your understanding.
Sincerely yours,
Michael Cheng
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.
2005 (beta2) and a disk for SQL Server 2005. If you install VS2005 you get
the April CTP SQL server but without Server Management Studio. If you
install SQL Server 2005, you get VS2005 but without the normal code
development templates. What's the recommended install sequence to get both?
And after several install/uninstall sequences I seem to have lost start menu
links to VS.Net 2003. Can I have VS.Net 2003 and VS.Net 2005 on the same
machine?
tks
Ron
Hi Ron,
Since SQL Server 2005 has not been public released yet, we will redirect
all SQL Server 2005 posts to the newsgroup below
http://communities.microsoft.com/new...lserver2005&sl
cid=us
Thanks so much for your understanding.
Sincerely yours,
Michael Cheng
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.
Subscribe to:
Comments (Atom)