Does SRS sql engine break things that used to work?

I've noticed that when I take stable SQL 2000 engines that are at SP3A where
the sqlservr executable is at build 8.00.760 and install SRS I get a new
build of the sql engine.
SQLServr.EXE build is 8.00.859 in SRS and things that used to work don't.
For example, stored procedure debug doesn't work at all on an SRS SQL Server.
I know I have seen a few other things that are now broke.
Does anyone know of any hotfixes that repair features that SRS breaks?RS doesn't do anything to the SQL Engine. If you are talkin about the 859
hotfix that we require in certain situations, there is a newer hotfix that
resolves the problem. You need to request it from product support. See
http://support.microsoft.com/default.aspx?scid=kb;en-us;831997.
Brian Welcker
Group Program Manager
Microsoft SQL Server
This posting is provided "AS IS" with no warranties, and confers no rights.
"Dan" <Dan@.discussions.microsoft.com> wrote in message
news:22305D8C-975B-4283-BC11-8264CDDEEB1E@.microsoft.com...
> I've noticed that when I take stable SQL 2000 engines that are at SP3A
> where
> the sqlservr executable is at build 8.00.760 and install SRS I get a new
> build of the sql engine.
> SQLServr.EXE build is 8.00.859 in SRS and things that used to work don't.
> For example, stored procedure debug doesn't work at all on an SRS SQL
> Server.
> I know I have seen a few other things that are now broke.
> Does anyone know of any hotfixes that repair features that SRS breaks?|||Thank-you for the quick reponse Brian.
I think maybe I wasn't too clear on my question.
If I install SQL Server 2000 Standard and then take it up to SP3A the build
level of my SQL engine is 760.
However, if I then apply SQL Reporting Services on top of this installation
my SQL engine gets taken up to build 859. Maybe this is not directly related
to SRS, but it certainly takes place upon installation of SRS.
At that point I no longer have the capability to debug stored procs (I
believe thru the sp_dbidbg xp).
So the downside is that I have to make a choice between having SRS and then
losing the capability of stored proc debug or not having SRS.
If there is a hotfix that addresses that I would love to have it.
thanks,
dan
"Brian Welcker [MS]" wrote:
> RS doesn't do anything to the SQL Engine. If you are talkin about the 859
> hotfix that we require in certain situations, there is a newer hotfix that
> resolves the problem. You need to request it from product support. See
> http://support.microsoft.com/default.aspx?scid=kb;en-us;831997.
>
> --
> Brian Welcker
> Group Program Manager
> Microsoft SQL Server
> This posting is provided "AS IS" with no warranties, and confers no rights.
> "Dan" <Dan@.discussions.microsoft.com> wrote in message
> news:22305D8C-975B-4283-BC11-8264CDDEEB1E@.microsoft.com...
> > I've noticed that when I take stable SQL 2000 engines that are at SP3A
> > where
> > the sqlservr executable is at build 8.00.760 and install SRS I get a new
> > build of the sql engine.
> >
> > SQLServr.EXE build is 8.00.859 in SRS and things that used to work don't.
> >
> > For example, stored procedure debug doesn't work at all on an SRS SQL
> > Server.
> >
> > I know I have seen a few other things that are now broke.
> >
> > Does anyone know of any hotfixes that repair features that SRS breaks?
>
>|||The RS setup proces does not touch the version of the SQL engine. We really
don't. We recommend a specific SQL engine hotfix during the installation
process that does do this. You would need to call product support for the
hotfix. I don't think it is generally downloadable.
--
Brian Welcker
Group Program Manager
Microsoft SQL Server
This posting is provided "AS IS" with no warranties, and confers no rights.
"Dan" <Dan@.discussions.microsoft.com> wrote in message
news:DA304849-A7E9-4A92-A39D-5E338227EF52@.microsoft.com...
> Thank-you for the quick reponse Brian.
> I think maybe I wasn't too clear on my question.
> If I install SQL Server 2000 Standard and then take it up to SP3A the
> build
> level of my SQL engine is 760.
> However, if I then apply SQL Reporting Services on top of this
> installation
> my SQL engine gets taken up to build 859. Maybe this is not directly
> related
> to SRS, but it certainly takes place upon installation of SRS.
> At that point I no longer have the capability to debug stored procs (I
> believe thru the sp_dbidbg xp).
> So the downside is that I have to make a choice between having SRS and
> then
> losing the capability of stored proc debug or not having SRS.
> If there is a hotfix that addresses that I would love to have it.
> thanks,
> dan
>
> "Brian Welcker [MS]" wrote:
>> RS doesn't do anything to the SQL Engine. If you are talkin about the 859
>> hotfix that we require in certain situations, there is a newer hotfix
>> that
>> resolves the problem. You need to request it from product support. See
>> http://support.microsoft.com/default.aspx?scid=kb;en-us;831997.
>>
>> --
>> Brian Welcker
>> Group Program Manager
>> Microsoft SQL Server
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> "Dan" <Dan@.discussions.microsoft.com> wrote in message
>> news:22305D8C-975B-4283-BC11-8264CDDEEB1E@.microsoft.com...
>> > I've noticed that when I take stable SQL 2000 engines that are at SP3A
>> > where
>> > the sqlservr executable is at build 8.00.760 and install SRS I get a
>> > new
>> > build of the sql engine.
>> >
>> > SQLServr.EXE build is 8.00.859 in SRS and things that used to work
>> > don't.
>> >
>> > For example, stored procedure debug doesn't work at all on an SRS SQL
>> > Server.
>> >
>> > I know I have seen a few other things that are now broke.
>> >
>> > Does anyone know of any hotfixes that repair features that SRS breaks?
>>sql

Does Debug > Build in Script Task actually do anything?

I'm looking for some way to verify the syntax, references, variables, etc. in my Script Tasks without having to run the package or the task.

There's a Build command in the Debug menu, but it doesn't seem to do anything -- certainly, not like the "Build Solution" in a Visual Studio project.

Am I missing something? Does Debug > Build in the VSA editor actually do anything?

Thanks!

- Mike

mike.groh wrote:

I'm looking for some way to verify the syntax, references, variables, etc. in my Script Tasks without having to run the package or the task.

There's a Build command in the Debug menu, but it doesn't seem to do anything -- certainly, not like the "Build Solution" in a Visual Studio project.

Am I missing something? Does Debug > Build in the VSA editor actually do anything?

Thanks!

- Mike

Mike,

I don't think it does for SSIS, no. This is a legacy from using someone else's IDE in order to facilitate scripting.

-Jamie

Does anyone use views?

Good Morning,
Does anyone have any use for views? I know how to build them, but i cant
find any use for them.
They are supposed to protected the data, protect how? does the users have
access to all the data if i dont use views? should i allways access views
insted of the tables to protected the data?
Thanks,
Bruno Nhttp://www.aspfaq.com/2537
This is my signature. It is a general reminder.
Please post DDL, sample data and desired results.
See http://www.aspfaq.com/5006 for info.
"Bruno N" <nylren@.hotmail.com> wrote in message
news:uKqcCWpPFHA.248@.TK2MSFTNGP15.phx.gbl...
> Good Morning,
> Does anyone have any use for views? I know how to build them, but i cant
> find any use for them.
> They are supposed to protected the data, protect how? does the users have
> access to all the data if i dont use views? should i allways access views
> insted of the tables to protected the data?
> Thanks,
> Bruno N
>|||Thank you ! :)
"Bruno N" <nylren@.hotmail.com> escreveu na mensagem
news:uKqcCWpPFHA.248@.TK2MSFTNGP15.phx.gbl...
> Good Morning,
> Does anyone have any use for views? I know how to build them, but i cant
> find any use for them.
> They are supposed to protected the data, protect how? does the users have
> access to all the data if i dont use views? should i allways access views
> insted of the tables to protected the data?
> Thanks,
> Bruno N
>|||To add to Aaron's response, another reason to use views and procs instead of
direct access to the underlying tables is that it provides a well-defined
application interface. As long as you don't change the interface, you can
freely modify table schema without changing application code.
Hope this helps.
Dan Guzman
SQL Server MVP
"Bruno N" <nylren@.hotmail.com> wrote in message
news:uKqcCWpPFHA.248@.TK2MSFTNGP15.phx.gbl...
> Good Morning,
> Does anyone have any use for views? I know how to build them, but i cant
> find any use for them.
> They are supposed to protected the data, protect how? does the users have
> access to all the data if i dont use views? should i allways access views
> insted of the tables to protected the data?
> Thanks,
> Bruno N
>|||Of course you should use them and not just because of security but for bette
r
performance too. This is a long story so I’ll give you some ref links to h
elp
you (my fingers hurts me already...this way typing day :))
http://www.microsoft.com/resources/... />
c3661.mspx
http://www.sqlteam.com/item.asp?ItemID=1015
http://www.sql-server-performance.com/indexed_views.asp
I couldn't find any article that exclusively focuses only on views and
security.
But I'll try to give you and idea with this example:
You have table Orders (OrderID int, CustomerID int,) which contains all
orders of your company.
You want to allow to group of users "A" to select, update and delete only
orders of Customer "C1" (CustomerID=1) and to group "B" only orders of
Customer "C2" (CustomerID=2) .
And, of course, at the same time you may deny all these privileges directly
on table Orders for both groups (A and B).
One of possible solutions (and recommended one) is two create 2 separate
Views: One which will display only orders of Customer "C1" (where
CustomerID=1) and other one which will display only orders of Customer "C2"
(where CustomerID=2) and on both views grant select, update, delete to its
respective groups (A->C1, B->C-2).
Hope this help.
Regards,
Marko Simic
"Bruno N" wrote:

> Good Morning,
> Does anyone have any use for views? I know how to build them, but i cant
> find any use for them.
> They are supposed to protected the data, protect how? does the users have
> access to all the data if i dont use views? should i allways access views
> insted of the tables to protected the data?
> Thanks,
> Bruno N
>
>|||Thank you all that helped me out!
Im gonna read them right now!
"Bruno N" <nylren@.hotmail.com> escreveu na mensagem
news:uKqcCWpPFHA.248@.TK2MSFTNGP15.phx.gbl...
> Good Morning,
> Does anyone have any use for views? I know how to build them, but i cant
> find any use for them.
> They are supposed to protected the data, protect how? does the users have
> access to all the data if i dont use views? should i allways access views
> insted of the tables to protected the data?
> Thanks,
> Bruno N
>

Does anyone use SSIS for database schema maintenance?

We currently use SSIS to build DTS packages in which we store changes
to our database schema, as well as scripts that need to be run upon
each release. This works well for small sets of changes that never
need to be updated or for architectures with only one database.

We store each of the changes included in the package in separate
files, which are tracked using version control. It is growing time
consuming to maintain parity between those files and what is in the
SSIS.

Furthermore, we have been unable to discover an easy way to load a
file's contents into a package SQL Task without opening the file and
copy-pasting the contents into a new SQL task.

ANY information at all would be extremely appreciated!On Feb 28, 2:54 pm, "Ben" <vanev...@.gmail.comwrote:

Quote:

Originally Posted by

We currently use SSIS to build DTS packages in which we store changes
to our database schema, as well as scripts that need to be run upon
each release. This works well for small sets of changes that never
need to be updated or for architectures with only one database.
>
We store each of the changes included in the package in separate
files, which are tracked using version control. It is growing time
consuming to maintain parity between those files and what is in the
SSIS.
>
Furthermore, we have been unable to discover an easy way to load a
file's contents into a package SQL Task without opening the file and
copy-pasting the contents into a new SQL task.
>
ANY information at all would be extremely appreciated!

Hi Ben,

There is a rock solid change management process for SQL Server
2000/2005 and it is provided by the DB Ghost toolset from
Innovartis.

The essence of the process is that you script out all the database
objects and lookup (static) data into individual CREATE / INSERT
scripts and put them under source control. The whole dev team then
checks these files out, makes the required changes to the CREATE
statements and checks them back in again (this can scale to thousand
of developers). Once you're ready to release the schema to the test
environment you use the DB Ghost Change Manager tool to make the
target database match the set of source scripts. If, for example, a
developer added a column to a table CREATE script then the Change
Manager would detect this and add the column to the target database
seamlessly.

Basically, DB Ghost enables you to develop in the same way as you do
for a greenfield (release 1) database for every subsequent release of
your schema without losing any data in the target database.

Our customers rave about DB Ghost and can't believe the cost savings
it brings - have a look for yourself :)

www.dbghost.com
Kind regards,

Malcolm