Perspectives 64 Bit Standard Edition - Not Supported

I received the following message:

Error1Errors related to feature availability and configuration: The 'Perspectives' feature is not included in the '64 Bit Standard Edition' SKU.

Does the 64 Bit developer Edition Support this?

Any suggestion we need to test and stage on our dev box before deploying to 64 bit enterprise prod box.

Thanks,

The 64 bit developer edition will allow you to create perspectives.

Here is a link with the different features for each edition:

http://msdn2.microsoft.com/en-us/library/ms143761.aspx

|||

Maybe the Deployment Server Edition property isn't set to Enterprise?

http://groups.google.com/group/microsoft.public.sqlserver.olap/browse_frm/thread/36855351fd3096b2/c7107957b1da7a13?#c7107957b1da7a13

>>

Aggregation function None is not allowed in Standard edition

From:

Chris Webb - view profile

Date:

Fri, Oct 20 2006 12:24 pm

Email:

Chris Webb <onlyforpostingtonewsgro...@.crossjoin.co.uk>

Groups:

microsoft.public.sqlserver.olap

Not yet rated

Rating:

show options

Reply | Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse | Find messages by this author

Hi Roger,

Have you set the Deployment Server Edition property appropriately on your project?

http://cwebbbi.spaces.live.com/blog/cns!7B84B0F2C239489A!856.entry

HTH,

Chris
--
Chris Webb, MVP
Analysis Services and MDX Consultancy: http://www.crossjoin.co.uk
Blog: http://cwebbbi.spaces.live.com/

sql

Persistent lookups

I read on the SQL Server 2008 Overview paper that there is a new "SSIS persistent lookup" feature.

Performing lookups is a common operation, especially in data warehousing, where fact records must use lookups to transform business keys to their corresponding surrogates. SQL Server Integration Services (SSIS) will increase the performance of lookups so that it scales to meet the largest tables.

I'd like to know how this is different from the existing 2005 lookup.

Marco Russo

http://www.sqlbi.eu

http://sqlblog.com/blogs/marco_russo

{disclaimer about unreleased software and unconfirmed features that can and will change before the release}

In SQL 2005, when the reference table is large and you are using fully cached mode, sometimes it takes longer to get the data out of reference table (OLEDB data source) and hash it for lookup, than to do the actual lookup on the input data.

In SQL 2008 we plan to allow persisting reference table and hashes, so that the reference table can be loaded faster from a local disk. You would not have to touch database that contains that reference table every time you use the lookup.

{disclaimer about unreleased software and unconfirmed features that can and will change before the release}

|||

Thank you - I hope to see early a new CTP to try this feature.

Marco

Permissions question.. (hey, didja miss me?)

Hi all,

Wow...since I've been gone, the search feature is apparently working again! Kewl!

However, after doing a search and not finding anything pertaining to my current issue, here I am again :D

I access a table on a linked server/database apart from my application's DB.

Every day, a process on the other server/DB drop and recreate the table...which, of course, zaps my user permissions. I then have to go into the Enterprise Mgr and re-enable my SELECT access to the table.

My question is this: Is there a way to auto-magically set my user ID on the linked server to give me access to the table without having to go in explicitly on a daily basis and re-enabling my UID Access rights.

This is the only table my user ID has been given access to on the remote server, so I am not able to simply set up my user ID on the remote system to "allow everything"

Am I missing something obvious? Do I have to create a SP on the remote server to do a daily GRANT SELECT ON Remote_Table TO Paul_Dammit after the table is rebuilt each day?

Suggestions?

It getsYour only option at the database level would be to give a user "carte-blanche" access to all of the tables within that database by making them a memeber of the db_datareader group.

For one specific table, I'd create a job that ran every 6 minutes or so, with one SQL step that tests to see if the table is there then grants permission if it is. I'm a "fewer moving pieces" kind of guy.

-PatP|||That's what I was afraid of, Pat...thanks for the reply! For the time being, I'll do that...I have a control table that I can read for a flag indicating when the drop/create has occurred, so I can simply does the grant when it happens.

I was just hoping to not have to add a job to someone else's DB...oh well...the price they pay for being so selective about the riff-raff they let in, I guess ;)

Thanks again!
Paul|||I guess from my perspective, if they see adding a one step job as too much of a pain, then they need to make you a member of db_datareader. That way they can do it once. Neither task takes over 40 seconds for a competent DBA, and once scheduled the only thing they need to do is watch for errors in the server log, which they'd better be doing anyway!

If they see this as a problem, they REALLY need to reevaluate their attitude. There might be collatoral duties that this job implies, but those are enforced by the organization and should be significantly less of a problem than granting the permissions manually.

-PatP