Calculated Cell

Some calculated cells need to be migrated from Analysis Services 2000 to 2005.
In 2000 we have them only on a single cube. In 2005 we are migrating the entire database as a cube and the cubes within 2000 are implemented as perspectives in 2005.

Is there any elegant way to ensure that the calculated cells do not affect other cubes(perspectives) in 2005?

You may want to ask this question in Analysis Services forum.

CAL users - 1 or many?

If you have an application that uses a single SQL logon to access the database, but that application is used by many people to access the database, do we require one CAL (for the app) or many (for each user)?For server/CAL licensing the licence agreement requires that you purchase a
licence for each user or device using the server. A user is an actual
person, not a login. That's my understanding.
From the licensing FAQ:
"A user CAL allows a particular user to gain access to licensed server
software from any number of devices."
http://www.microsoft.com/sql/howtobuy/faq.asp
--
David Portas
SQL Server MVP
--

CAL users - 1 or many?

If you have an application that uses a single SQL logon to access the databa
se, but that application is used by many people to access the database, do w
e require one CAL (for the app) or many (for each user)?For server/CAL licensing the licence agreement requires that you purchase a
licence for each user or device using the server. A user is an actual
person, not a login. That's my understanding.
From the licensing FAQ:
"A user CAL allows a particular user to gain access to licensed server
software from any number of devices."
http://www.microsoft.com/sql/howtobuy/faq.asp
David Portas
SQL Server MVP
--

CAL users - 1 or many?

If you have an application that uses a single SQL logon to access the database, but that application is used by many people to access the database, do we require one CAL (for the app) or many (for each user)?
For server/CAL licensing the licence agreement requires that you purchase a
licence for each user or device using the server. A user is an actual
person, not a login. That's my understanding.
From the licensing FAQ:
"A user CAL allows a particular user to gain access to licensed server
software from any number of devices."
http://www.microsoft.com/sql/howtobuy/faq.asp
David Portas
SQL Server MVP

cacheRemove

I have a stored proc with several input parameters and it runs very efficient
(14 seconds) on my dev server (PII-450 single processor, 512 mb ram), even
when drastically changing the parameters. I run the same stored proc on my
production server (dual Pentium 1 ghz, 1 or 2 gb ram) and it will take up to
15 minutes. The CPU usage on the production server is very low. When we ran a
trace on production we found that it was removing the cache and then of
course the cache would be missing and it would recompile - sometimes up to 10
or 15 times through the execution of the store proc. It doesn't do the
recompiling on the dev server. We feel certain that there must be a
difference in the configuration of either SQL server between the servers or
Windows. We aren't sure where to start looking.
It might be that the connection in which you are running the sp has
different enviorment settings than the dev connection. Run a profile trace
on both with the existing connection and connection Login to see if they are
the same. The sp can be poorly written and force recompilation as well. Do
you have temp tables in it? Have a look here:
http://support.microsoft.com/default.aspx?kbid=243586
Andrew J. Kelly SQL MVP
"James" <James@.discussions.microsoft.com> wrote in message
news:76AECD82-262E-428C-B0D9-E03A9FC49BCD@.microsoft.com...
>I have a stored proc with several input parameters and it runs very
>efficient
> (14 seconds) on my dev server (PII-450 single processor, 512 mb ram), even
> when drastically changing the parameters. I run the same stored proc on my
> production server (dual Pentium 1 ghz, 1 or 2 gb ram) and it will take up
> to
> 15 minutes. The CPU usage on the production server is very low. When we
> ran a
> trace on production we found that it was removing the cache and then of
> course the cache would be missing and it would recompile - sometimes up to
> 10
> or 15 times through the execution of the store proc. It doesn't do the
> recompiling on the dev server. We feel certain that there must be a
> difference in the configuration of either SQL server between the servers
> or
> Windows. We aren't sure where to start looking.

cacheRemove

I have a stored proc with several input parameters and it runs very efficient
(14 seconds) on my dev server (PII-450 single processor, 512 mb ram), even
when drastically changing the parameters. I run the same stored proc on my
production server (dual Pentium 1 ghz, 1 or 2 gb ram) and it will take up to
15 minutes. The CPU usage on the production server is very low. When we ran a
trace on production we found that it was removing the cache and then of
course the cache would be missing and it would recompile - sometimes up to 10
or 15 times through the execution of the store proc. It doesn't do the
recompiling on the dev server. We feel certain that there must be a
difference in the configuration of either SQL server between the servers or
Windows. We aren't sure where to start looking.It might be that the connection in which you are running the sp has
different enviorment settings than the dev connection. Run a profile trace
on both with the existing connection and connection Login to see if they are
the same. The sp can be poorly written and force recompilation as well. Do
you have temp tables in it? Have a look here:
http://support.microsoft.com/default.aspx?kbid=243586
--
Andrew J. Kelly SQL MVP
"James" <James@.discussions.microsoft.com> wrote in message
news:76AECD82-262E-428C-B0D9-E03A9FC49BCD@.microsoft.com...
>I have a stored proc with several input parameters and it runs very
>efficient
> (14 seconds) on my dev server (PII-450 single processor, 512 mb ram), even
> when drastically changing the parameters. I run the same stored proc on my
> production server (dual Pentium 1 ghz, 1 or 2 gb ram) and it will take up
> to
> 15 minutes. The CPU usage on the production server is very low. When we
> ran a
> trace on production we found that it was removing the cache and then of
> course the cache would be missing and it would recompile - sometimes up to
> 10
> or 15 times through the execution of the store proc. It doesn't do the
> recompiling on the dev server. We feel certain that there must be a
> difference in the configuration of either SQL server between the servers
> or
> Windows. We aren't sure where to start looking.

cacheRemove

I have a stored proc with several input parameters and it runs very efficien
t
(14 seconds) on my dev server (PII-450 single processor, 512 mb ram), even
when drastically changing the parameters. I run the same stored proc on my
production server (dual Pentium 1 ghz, 1 or 2 gb ram) and it will take up to
15 minutes. The CPU usage on the production server is very low. When we ran
a
trace on production we found that it was removing the cache and then of
course the cache would be missing and it would recompile - sometimes up to 1
0
or 15 times through the execution of the store proc. It doesn't do the
recompiling on the dev server. We feel certain that there must be a
difference in the configuration of either SQL server between the servers or
Windows. We aren't sure where to start looking.It might be that the connection in which you are running the sp has
different enviorment settings than the dev connection. Run a profile trace
on both with the existing connection and connection Login to see if they are
the same. The sp can be poorly written and force recompilation as well. Do
you have temp tables in it? Have a look here:
http://support.microsoft.com/default.aspx?kbid=243586
Andrew J. Kelly SQL MVP
"James" <James@.discussions.microsoft.com> wrote in message
news:76AECD82-262E-428C-B0D9-E03A9FC49BCD@.microsoft.com...
>I have a stored proc with several input parameters and it runs very
>efficient
> (14 seconds) on my dev server (PII-450 single processor, 512 mb ram), even
> when drastically changing the parameters. I run the same stored proc on my
> production server (dual Pentium 1 ghz, 1 or 2 gb ram) and it will take up
> to
> 15 minutes. The CPU usage on the production server is very low. When we
> ran a
> trace on production we found that it was removing the cache and then of
> course the cache would be missing and it would recompile - sometimes up to
> 10
> or 15 times through the execution of the store proc. It doesn't do the
> recompiling on the dev server. We feel certain that there must be a
> difference in the configuration of either SQL server between the servers
> or
> Windows. We aren't sure where to start looking.

Bypass transaction log

Hi,
I have a database in full mode, can i issue a delete
command that deletes a single row bypassing the
transaction log?
Thanks in advance
MiguelYou can use TRUNCATE TABLE to delete the contents of the
entire table without logging. I am unaware of any way to
do this at the row level.
>--Original Message--
>Hi,
>I have a database in full mode, can i issue a delete
>command that deletes a single row bypassing the
>transaction log?
>Thanks in advance
>Miguel
>.
>|||That's not possible.
Linchi
>--Original Message--
>Hi,
>I have a database in full mode, can i issue a delete
>command that deletes a single row bypassing the
>transaction log?
>Thanks in advance
>Miguel
>.
>

Button That Execute Stored Procedure

I have a button in a form that I want to execute a simple stored procedure to insert a single value into a database table.
The Stored Procedure is:
=================
CREATE PROCEDURE bplog_insert_invoice_detail (@.invo_Id Int) AS
INSERT INTO Invoice_Detail
(Invo_Id)
VALUES(@.Invo_Id)
GO
=================
How do i pass the value from and text field (@.invo_id) and execute the stored procedure when a button is clicked.
Regards.

This is untested, but it should work:

SqlConnection cn = new SqlConnection(connectionString);
SqlComment cmd = cn.CreateCommand();

cmd.CommandText = "bplog_insert_invoice_detail";
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter parm = new SqlParameter("@.invo_Id", SqlDbType.Int)
parm.Value = parameterValue;
cmd.Parameters.Add(parm);
cmd.ExecuteNonQuery();

Hope that helps.