Dynamic Granting of Insert Permissions?

I need to restrict insert permissions on a single table to a pre defined time window each day.

One way would be to craete a new user in NT and restrict login to the time window, and then only grant insert permissions on the table to this user.

better, though, would be to achieve this at DB level. Is this possible?Why would you ever need to do this at the DB level?

You might be able to set up a trigger to remove the inserted row after it is added if the time is in a range.

Better would be to have your application logic restrict access to the insert statement between certain times.

Dynamic disk

Does clustering supports dynamic disk mirroring with SAN? As cluster
has single point of failure of disk, we want to mirror the databases.
Any ideas would be appreciated.
Thanks
Clustering does not support dynamic disks.
http://support.microsoft.com/default...b;EN-US;284134
http://support.microsoft.com/default...b;en-us;237853
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering
http://www.msmvps.com/clustering - Blog
"tram" <tram_e@.hotmail.com> wrote in message
news:1108518044.708003.277010@.z14g2000cwz.googlegr oups.com...
> Does clustering supports dynamic disk mirroring with SAN? As cluster
> has single point of failure of disk, we want to mirror the databases.
> Any ideas would be appreciated.
> Thanks
>
|||As Rodney pointed out, Clustering does not support Windows Dynamic Disks.
SAN vendors may provide some LUN mirroring capabilities, but that is outside
the scope of SQL server.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"tram" <tram_e@.hotmail.com> wrote in message
news:1108518044.708003.277010@.z14g2000cwz.googlegr oups.com...
> Does clustering supports dynamic disk mirroring with SAN? As cluster
> has single point of failure of disk, we want to mirror the databases.
> Any ideas would be appreciated.
> Thanks
>

Dynamic Dataset for Chart in Report

Is it possible to dynamically set the dataset for a chart on a report?

What I'm trying to do is generate a single chart on a report. Depending on what items a user selects as parameters would determine the dataset used. Unfortunately, one dataset comes from Oracle the other from SQLServer.

Thanks!

You could have two charts - one per dataset. Set the chart.Visibility property so that only one chart is visible depending on the selected parameter value.

-- Robert

Dynamic database tables

How does one make a database table dynamic?
I need to have a single report display data from different SQL tables
depending on which client is viewing the data.Here's an example:
1. Run the following static SQL in data pane of report designer: select
name, xtype, crdate from sysobjects
2. Switch to Layout view. This creates the fields in fields window.
3. Go back to the data pane and pase the following query into it: ="select
name, xtype, crdate from " & iif(LCase(User!UserID) = "redmond\ravimu",
"pubs", "northwind") & "..sysobjects where type = 'u'". This will
dynamically source the data from diferent table depending on the current
user.
Notes:
1. Assumption: Table schemas are the same.
2. If the target tables have same number of columna but different names, you
can map each column name to a unique alias as follows: select name As Col1,
xtype As Col2, crdate As Col3 from sysobjects
3. If you have many users, you may want to replace iif() with Switch()
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vblr7/html
/vafctswitch.asp)
--
Ravi Mumulla (Microsoft)
SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"jimmy stewart" <jims@.wolfmagick.com> wrote in message
news:u9$uYmQbEHA.3944@.tk2msftngp13.phx.gbl...
> How does one make a database table dynamic?
> I need to have a single report display data from different SQL tables
> depending on which client is viewing the data.
>

Dynamic Data sets in reports

Hi,

I'm using a matrix report where in i want to use two datasets in the same report. How can i make the dataset dynamic for a single report.

Regards

Can the two datasets be accessed from the same datasource/connection?

Can they be made to "express themselves" using exactly the same column names ?

>L<

dwh problem

Hi,
I have to choose between
a) using one single fact table
b) using one fact table and several dimension tables
I know that if you have no dimension tables (i.e. you store all the
information on one single fact table) your sql will not include any joins. I
understand joins penalize performance so it would make sense to go for this
option. Can someone tell me if a star schema approach with surrogate keys on
the fact table pointing to each dimension table would be less performant than
the single fact table approach? What would be more efficient if I want to use
Business Objects as the reporting tool? What are the pros and cons of each
option?
If anyone has previously had to make a similar decision I would very much
appreciate the help.
Thanks a lot,
Roberto
Hi rufian,
I can't completely answer your question, but my experience so far has been
that using the surrogate keys is worth doing. I have built fact tables before
that should everything in one table and it didn't significantly improve
performance.
Analysis services 2005 also seems to be happier with the star schema, but I
don't know much about it.
One of the biggest benefits of the star schema is that you can add more
attributes and dimensions much more easily.
If you know how big your fact table will be, then the decision may be made
for you. As soon as your fact table starts getting big, you should use
dimension tables. If you have 1 million rows in the fact table, there is no
way I would skip the dimension tables. Even for 100,000 I probably wouldn't
skip them.
I hope that helps.
"rufian" wrote:

> Hi,
> I have to choose between
> a) using one single fact table
> b) using one fact table and several dimension tables
> I know that if you have no dimension tables (i.e. you store all the
> information on one single fact table) your sql will not include any joins. I
> understand joins penalize performance so it would make sense to go for this
> option. Can someone tell me if a star schema approach with surrogate keys on
> the fact table pointing to each dimension table would be less performant than
> the single fact table approach? What would be more efficient if I want to use
> Business Objects as the reporting tool? What are the pros and cons of each
> option?
> If anyone has previously had to make a similar decision I would very much
> appreciate the help.
> Thanks a lot,
> Roberto
>
|||I completely agree: the single fact table is not easy to manage in the
future; moreover, it is less performant due to the very high
denormalization (you create an higher I/O work for SQL Server).
Marco Russo
http://www.sqlbi.eu
http://www.sqljunkies.com/weblog/sqlbi
Eager to Learn ha scritto:
[vbcol=seagreen]
> Hi rufian,
> I can't completely answer your question, but my experience so far has been
> that using the surrogate keys is worth doing. I have built fact tables before
> that should everything in one table and it didn't significantly improve
> performance.
> Analysis services 2005 also seems to be happier with the star schema, but I
> don't know much about it.
> One of the biggest benefits of the star schema is that you can add more
> attributes and dimensions much more easily.
> If you know how big your fact table will be, then the decision may be made
> for you. As soon as your fact table starts getting big, you should use
> dimension tables. If you have 1 million rows in the fact table, there is no
> way I would skip the dimension tables. Even for 100,000 I probably wouldn't
> skip them.
> I hope that helps.
> "rufian" wrote:

dwh problem

Hi,
I have to choose between
a) using one single fact table
b) using one fact table and several dimension tables
I know that if you have no dimension tables (i.e. you store all the
information on one single fact table) your sql will not include any joins. I
understand joins penalize performance so it would make sense to go for this
option. Can someone tell me if a star schema approach with surrogate keys on
the fact table pointing to each dimension table would be less performant tha
n
the single fact table approach? What would be more efficient if I want to us
e
Business Objects as the reporting tool? What are the pros and cons of each
option?
If anyone has previously had to make a similar decision I would very much
appreciate the help.
Thanks a lot,
RobertoHi rufian,
I can't completely answer your question, but my experience so far has been
that using the surrogate keys is worth doing. I have built fact tables befor
e
that should everything in one table and it didn't significantly improve
performance.
Analysis services 2005 also seems to be happier with the star schema, but I
don't know much about it.
One of the biggest benefits of the star schema is that you can add more
attributes and dimensions much more easily.
If you know how big your fact table will be, then the decision may be made
for you. As soon as your fact table starts getting big, you should use
dimension tables. If you have 1 million rows in the fact table, there is no
way I would skip the dimension tables. Even for 100,000 I probably wouldn't
skip them.
I hope that helps.
"rufian" wrote:

> Hi,
> I have to choose between
> a) using one single fact table
> b) using one fact table and several dimension tables
> I know that if you have no dimension tables (i.e. you store all the
> information on one single fact table) your sql will not include any joins.
I
> understand joins penalize performance so it would make sense to go for thi
s
> option. Can someone tell me if a star schema approach with surrogate keys
on
> the fact table pointing to each dimension table would be less performant t
han
> the single fact table approach? What would be more efficient if I want to
use
> Business Objects as the reporting tool? What are the pros and cons of each
> option?
> If anyone has previously had to make a similar decision I would very much
> appreciate the help.
> Thanks a lot,
> Roberto
>|||I completely agree: the single fact table is not easy to manage in the
future; moreover, it is less performant due to the very high
denormalization (you create an higher I/O work for SQL Server).
Marco Russo
http://www.sqlbi.eu
http://www.sqljunkies.com/weblog/sqlbi
Eager to Learn ha scritto:
[vbcol=seagreen]
> Hi rufian,
> I can't completely answer your question, but my experience so far has been
> that using the surrogate keys is worth doing. I have built fact tables bef
ore
> that should everything in one table and it didn't significantly improve
> performance.
> Analysis services 2005 also seems to be happier with the star schema, but
I
> don't know much about it.
> One of the biggest benefits of the star schema is that you can add more
> attributes and dimensions much more easily.
> If you know how big your fact table will be, then the decision may be made
> for you. As soon as your fact table starts getting big, you should use
> dimension tables. If you have 1 million rows in the fact table, there is n
o
> way I would skip the dimension tables. Even for 100,000 I probably wouldn'
t
> skip them.
> I hope that helps.
> "rufian" wrote:
>