Showing posts with label admin. Show all posts
Showing posts with label admin. Show all posts

Wednesday, March 7, 2012

Assign Cube User Access Without Being Admin?

Is it possible to set up a "low-level" administrator account in Analysis Services that only allows a user to assign other users to a particular Role?

We have an enterprise app where users in the field will need to call a help desk to gain access to the cube, but we only want the help desk people to be able to perform that one function. We would like to avoid building a custom admin tool that provides the proper restriction. Ideally, the help desk would use SQL Server Management Studio to perform this specific task while prohibiting any other admin abilities. Is this possible?

--
Joe

No, unfortunatelly this is not possible. If you already have tool by which helpdesk can assign users to existing NT groups, then you can include these groups into SSAS roles - and helpdesk personell won't need any access to SSAS.

Friday, February 24, 2012

ASPNETDB to another database

Hi there readers of this post,

Do you know how to transfer the database (ASPNETDB.mdf) tables made by the ASP.NET admin tool into another database?

I want to run everything from 1 database.

regards

Sat

Hi

What you can do is

Go to folder

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727

in the above folder there is a file named "aspnet_regsql" run this file

it will ask you whether a default database or a partucular database in which you would like

to keep this. if you set it as default then it creates a new database"aspnetDB"

if you point to another databse[ say northwind] then all the tables necessary for member ship

do come in to northwind.

Try this if you still find issues let me know

With regards

Sridhar

Thursday, February 16, 2012

asp.net Stored Procedures vs not

Hey,

I'm developing an asp.net page that will be looking at having approx 500 000 members.

I have be warned by my webhost admin not to use stored procedures. They say that they are much less efficient with large databases. Harder to manage, and will lock me down.

This struck me as odd, as everything I have read and done so far points to SP's being the way to go.

People that have experience with large databases, what advice / comments can you give me? Should I use stored procedures, or should I put all my sql in the asp.net pages.

My situation, asp.net, ms sql. I will be storing the users in user groups, each group will have its own table containing member information, each group will have between 20 and 500 members. Each group will also have 2-3 tables associated with it. (not sure if this information is relevant, but if it is, there ya go).

ThanksWhat?? The only way I could see it being harder to manage would be if they didn't know what the heck they were doing with stored procedures...

I've been developing web sites with database interaction for the last 6 years or so and IMO stored procs are a must.

Stored procedures are less efficient with large databases?? Um,... no,... especially not if you are comparing them to straight sql statements being executed... yes, you can get problems with execution paths not using the right indexes but if you know what you are doing it's not a big issue...|||Phew, thought I was going mad. Because I couldn't understand why not to use SP's, lol.

One question though. (here we see the n00b emerge) lol

-Quote
yes, you can get problems with execution paths not using the right indexes but if you know what you are doing it's not a big issue...

I don't follow what people mean when they say indexing etc. I've sort of learn sql by playing and reading forums. I've never actually found a good book I thought worth buying (or resource really) other than these forums, lol.

How can I avoid bad indexing? What is indexing? This may be big and hard to answer, so if you'd rather throw me at a resource (online or book), do it, lol. A little reading never hurt anybody. It's a lot of 'reading the wrong stuff' that hurts, lol.

Thanks again rokslide,
-Ashleigh|||In short an index is exactly that....

Think about a book,.. it has an index that tells you where to find what you are looking for...

Tables are like books and they can have indexes,...

The indexes help "organise" the data and mean that when you are in there looking for things you can find it alot faster... Indexes will make the database take up more space but generally the performance increase and the reduced table locking will be well worth it...

It's difficult to say exactly what is bad indexing. I guess it's indexes that are too large for the return they give...

The problem I was referring to is... stored procedures are compiled, when they compile the build and execution plan and decide what indexes they will use. Sometimes they will not pick the best index and sometimes the best index will change depending on the data in the table. When this helps you need to force the stored procedure to build a new execution plan. This is probably not technically right (eg I have the phrases wrong) but the gist of it is correct from my understanding...

Deciding what indexes you want to build really depends on what you want to search the table for and how the data in the table relates to other things... drop me a PM (do we have PM's here?) and I can help you if you want to provide specific details.

Thursday, February 9, 2012

ASP.NET 2.0 and SQL2000

Hi,

I have made a web application using SQL Server 2005Express with a few admin pages that require login. I used the SQLServer Managment Studio Express to setup users and groups and it worksfine.

But the web server has SQL Server 2000 and all I get is auser id and password to access the database. It seems I cannot use theLogin control I put on my "login.aspx" page becuase it uses theintegrated authentication which chokes on 2000. I am afraid I wonlt beable to use some of the 2.0 features such as profiles, ...

Isthis the way 2.0 works with SQL Server 2000? Should I ditch the ISP ifthey only give me a single access to database with no provisions tocreate users. (I was told I had to create a "Users" table and manuallyassign ids and passwords and that I can only use the user id andpassword they supplied to setup the connection string in the script.)

I appreciate your help.

Single login connectionstrings are the more natural way to do something like this - the 'users' you are referring to, are users of your application, and don't need to be users in the database - you wouldn't want them to have access to your database, in fact.

And you can easily setup a membership/roles scenario, in the database (2000 or 2005) with the connectionstring they give you.

|||

Thanks for the info.

When is it appropriate to add users and groups using the SQL Server Management Studio?

Canyou please point me to a document or article that describes how tosetup and use membership/roles using only the connection string?

Thank you.