Showing posts with label business. Show all posts
Showing posts with label business. Show all posts

Wednesday, March 21, 2012

Failed to connect to SQL Server 2005 database form Microsoft Office business scorecard Manager 2

Hi,all BI experts here,

Thank you very much for your kind attention.

I am having a problem with connecting to SQL Server 2005 database from Office Business Scorecard Manager 2005 (the connection string i am using is: provider=SQLOLEDB;Data source=server_name; Initial catalog=database_name). But the connection failed. Would please any experts here shed me any light on what is the problem and how to fix it then? As there is no any forum for Office Business Scrorecard manager 2005. Therefore I post my thread here as it is related to the connection to SQL Server 2005 database engine, thought here is the best place for this question.

Thank you very in advance for your kind advices and help. And I am looking forward to hearing from you soon.

With best regards,

Yours sincerely,

Have you enabled remote connections on your SQL Server instance?|||

Hi, Michael,

Thanks a lot for your reply. Yes, though I am connecting to the SQL Server 2005 database on the local host, but yes, I have set both local and remote connection enabled for the database server instance. But it is not working. I am looking forward to hearing from you further for your help.

With best regards,

Yours sincerely,

|||

But my connection to SQL Server 2005 OLAP cubes is ok though. Dont really know what exactly the problem is. Still struggling to figure it out. Would please any experts here give me any help?

Thanks a lot and I am looking forward to hearing from you shortly.

With best regards.,

Yours sincerely,

|||Can you post the exact error message that you are seeing?|||

Hi, Michael,

Thank you very much for your reply.

The connection error I have got is always like this: The Business Scorecard Manager server could not conenct to the data soure. Verify that all of the required data has been entered in the boxes and that the connection information is correct.

Thank you very much for your help and I am looking forward to hearing from you further shortly.

With best regards,

Yours sincerely,

|||Does your sqlserver allow remote connection?

exec sp_configure 'show',1
reconfigure with override
go
--check the current setting
exec sp_configure 'remote access'
go
--allow remote access
exec sp_configure 'remote access',1
reconfigure with override
go

--need to restart to take effect.

Friday, March 9, 2012

Fail to save Maintenace Plan using 'sa' with blank password

sa with no password is not exactly supported (for reasons which should be
obvious). What is your business need to leave this password blank?
"Michael Bergman" <simutek@.community.nospam> wrote in message
news:B90366AD-B401-43EA-AA3E-3A86939AABF2@.microsoft.com...
> Is it not supported to create a Maintenance Plan when logged in as 'sa'
> with
> blank password in SQL Server Management Studio?
> When logged in as 'sa' I get the following error when trying to save a
> Maintenance Plan:
> One or more arguments are invalid
> But if I login using Windows Authentication, or add a password to 'sa', I
> can successfully save a Maintenance Plan. I am using SQL Server 2005 SP1
> with
> Integration Services installed.
> --
> Regards,
> Michael Bergman
> SIMUTEK AB
>
This was an issue for one of our customers. We recommend strong passwords.
However, some customers still use blank password from old habit.
Now that I have confirmed that creating Maintenance Plans using blank
password is not supported, this might encourage our customers to change to a
strong password.
Regards,
Michael Bergman
SIMUTEK AB
"Aaron Bertrand [MVP]" wrote:

> sa with no password is not exactly supported (for reasons which should be
> obvious). What is your business need to leave this password blank?
>
>
> "Michael Bergman" <simutek@.community.nospam> wrote in message
> news:B90366AD-B401-43EA-AA3E-3A86939AABF2@.microsoft.com...
>
>

Sunday, February 19, 2012

extracting SP header information

Greetings,
We have a business requirement to somehow extract the SP header from
syscomments where available. This is done from a COM+ component using
ADO in order to verify whether SP arguments are specified correctly
from a client application, primarily during integration testing. We
know to use sp_helptext, but there is a slight issue...
Parsing around comments is not a problem using block (/* ... */)
commenting style, however single line (-- ...) comments may pose a
problem. It appears as though syscomments spans such comment lines
across table rows. So we end up with something like this:
...
-- blah blah blah (exceeds 255 characters)
blah blah blah (remaining comment
...
This could present some challenges. Is there a safe (and sane) method
of determining when this is the case and making the appropriate
adjustments to the COM+ code?
If we can get past this "little" issue then I am fairly confident we
can parse the remainder of the SP header for the desired argument
information.
Any insight anyone can offer wouldb e much appreciated.
Thanks,
Michael Powell
Parsing syscomments text seems a bit of a kluge to me. If all you are
interested in is parameter names and data types, it would probably be better
to query INFORMATION_SCHEMA.PARAMETERS.
Hope this helps.
Dan Guzman
SQL Server MVP
"Mike" <mwpowellnm@.comcast.net> wrote in message
news:1133291509.605075.241180@.f14g2000cwb.googlegr oups.com...
> Greetings,
> We have a business requirement to somehow extract the SP header from
> syscomments where available. This is done from a COM+ component using
> ADO in order to verify whether SP arguments are specified correctly
> from a client application, primarily during integration testing. We
> know to use sp_helptext, but there is a slight issue...
> Parsing around comments is not a problem using block (/* ... */)
> commenting style, however single line (-- ...) comments may pose a
> problem. It appears as though syscomments spans such comment lines
> across table rows. So we end up with something like this:
> ...
> -- blah blah blah (exceeds 255 characters)
> blah blah blah (remaining comment
> ...
> This could present some challenges. Is there a safe (and sane) method
> of determining when this is the case and making the appropriate
> adjustments to the COM+ code?
> If we can get past this "little" issue then I am fairly confident we
> can parse the remainder of the SP header for the desired argument
> information.
> Any insight anyone can offer wouldb e much appreciated.
> Thanks,
> Michael Powell
>
|||Wow, you are correct. This is about as direct a route as one can expect
querying for parameter information. One thing, however, how do we get
at information such as the default arguments? This doesn't appear to be
available from INFORMATION_SCHEMA.PARAMETERS?
|||Aside from parsing the proc header, you can use SMO to get stored procedure
default parameters. SMO is a .Net-based API introduced in SQL 2005 and
version 2.0 of the .Net framework so it needs to be called from managed
code. If your existing COM component is strictly unmanaged, you might find
it easier to wrap the needed SMO stuff in a separate assembly so that you
invoke it using COM interop.
Hope this helps.
Dan Guzman
SQL Server MVP
"Mike" <mwpowellnm@.comcast.net> wrote in message
news:1133327307.157086.42280@.g47g2000cwa.googlegro ups.com...
> Wow, you are correct. This is about as direct a route as one can expect
> querying for parameter information. One thing, however, how do we get
> at information such as the default arguments? This doesn't appear to be
> available from INFORMATION_SCHEMA.PARAMETERS?
>
|||Please forgive my ignorance, the only reference I see to SMO is in the
MS SOAP toolkit. Is there a primer section that could introduce me to
it? Something that explains what it is, how to begin using it, etc,
etc? From Visual Studio .NET (2002) I found the references. From VS
..NET 2003 I found no such references. Or maybe I'm missing it?
|||We may pursue the SMO option (research on the topic pending). Back to
our original query though... Are there any practical ways to address
the above scenario? Short of assuming that the code must be good
syntactically or it wouldn't have been applied to the syscomments
table. If that is true, then any tokens which fall outside the scope of
available SQL tokens are probably invalid and belong to the comment.
Then we're looking for the first token which appears with a '@.' and
which is followed by a valid type token? (Thinking out loud...)
|||<quote>
Please forgive my ignorance, the only reference I see to SMO is in the
MS SOAP toolkit. Is there a primer section that could introduce me to
it? Something that explains what it is, how to begin using it, etc,
etc? From Visual Studio .NET (2002) I found the references. From VS
..NET 2003 I found no such references. Or maybe I'm missing it?
</quote>
For all,
http://msdn2.microsoft.com/en-us/library/ms162169.aspx
|||Parsing ad-hoc text is a real pain, even when limited to the header.
Personally, I wouldn't even go there, given the SMO alternative. Consider
cases like:
CREATE PROC MyProc
--@.MyParm1,
@.MyParm2 int = 1,
@.MyParm3 varchar(10) = '@.MyParm4 int',
@.MyParm5 int = 1, @.MyParm6 int = 1 --@.MyParam7 int
AS
...
Hope this helps.
Dan Guzman
SQL Server MVP
"Mike" <mwpowellnm@.comcast.net> wrote in message
news:1133363064.039670.317640@.g14g2000cwa.googlegr oups.com...
> We may pursue the SMO option (research on the topic pending). Back to
> our original query though... Are there any practical ways to address
> the above scenario? Short of assuming that the code must be good
> syntactically or it wouldn't have been applied to the syscomments
> table. If that is true, then any tokens which fall outside the scope of
> available SQL tokens are probably invalid and belong to the comment.
> Then we're looking for the first token which appears with a '@.' and
> which is followed by a valid type token? (Thinking out loud...)
>
|||As you've probably discovered by now, .Net Framework 2.0 requirement implies
that you'll need to develop using Visual Studio 2005 or at least the 2.0
framework SDK.
Hope this helps.
Dan Guzman
SQL Server MVP
"Mike" <mwpowellnm@.comcast.net> wrote in message
news:1133362835.430233.58550@.g47g2000cwa.googlegro ups.com...
> Please forgive my ignorance, the only reference I see to SMO is in the
> MS SOAP toolkit. Is there a primer section that could introduce me to
> it? Something that explains what it is, how to begin using it, etc,
> etc? From Visual Studio .NET (2002) I found the references. From VS
> .NET 2003 I found no such references. Or maybe I'm missing it?
>

extracting SP header information

Greetings,
We have a business requirement to somehow extract the SP header from
syscomments where available. This is done from a COM+ component using
ADO in order to verify whether SP arguments are specified correctly
from a client application, primarily during integration testing. We
know to use sp_helptext, but there is a slight issue...
Parsing around comments is not a problem using block (/* ... */)
commenting style, however single line (-- ...) comments may pose a
problem. It appears as though syscomments spans such comment lines
across table rows. So we end up with something like this:
..
-- blah blah blah (exceeds 255 characters)
blah blah blah (remaining comment
..
This could present some challenges. Is there a safe (and sane) method
of determining when this is the case and making the appropriate
adjustments to the COM+ code?
If we can get past this "little" issue then I am fairly confident we
can parse the remainder of the SP header for the desired argument
information.
Any insight anyone can offer wouldb e much appreciated.
Thanks,
Michael PowellParsing syscomments text seems a bit of a kluge to me. If all you are
interested in is parameter names and data types, it would probably be better
to query INFORMATION_SCHEMA.PARAMETERS.
Hope this helps.
Dan Guzman
SQL Server MVP
"Mike" <mwpowellnm@.comcast.net> wrote in message
news:1133291509.605075.241180@.f14g2000cwb.googlegroups.com...
> Greetings,
> We have a business requirement to somehow extract the SP header from
> syscomments where available. This is done from a COM+ component using
> ADO in order to verify whether SP arguments are specified correctly
> from a client application, primarily during integration testing. We
> know to use sp_helptext, but there is a slight issue...
> Parsing around comments is not a problem using block (/* ... */)
> commenting style, however single line (-- ...) comments may pose a
> problem. It appears as though syscomments spans such comment lines
> across table rows. So we end up with something like this:
> ...
> -- blah blah blah (exceeds 255 characters)
> blah blah blah (remaining comment
> ...
> This could present some challenges. Is there a safe (and sane) method
> of determining when this is the case and making the appropriate
> adjustments to the COM+ code?
> If we can get past this "little" issue then I am fairly confident we
> can parse the remainder of the SP header for the desired argument
> information.
> Any insight anyone can offer wouldb e much appreciated.
> Thanks,
> Michael Powell
>|||Wow, you are correct. This is about as direct a route as one can expect
querying for parameter information. One thing, however, how do we get
at information such as the default arguments? This doesn't appear to be
available from INFORMATION_SCHEMA.PARAMETERS?|||Aside from parsing the proc header, you can use SMO to get stored procedure
default parameters. SMO is a .Net-based API introduced in SQL 2005 and
version 2.0 of the .Net framework so it needs to be called from managed
code. If your existing COM component is strictly unmanaged, you might find
it easier to wrap the needed SMO stuff in a separate assembly so that you
invoke it using COM interop.
Hope this helps.
Dan Guzman
SQL Server MVP
"Mike" <mwpowellnm@.comcast.net> wrote in message
news:1133327307.157086.42280@.g47g2000cwa.googlegroups.com...
> Wow, you are correct. This is about as direct a route as one can expect
> querying for parameter information. One thing, however, how do we get
> at information such as the default arguments? This doesn't appear to be
> available from INFORMATION_SCHEMA.PARAMETERS?
>|||Please forgive my ignorance, the only reference I see to SMO is in the
MS SOAP toolkit. Is there a primer section that could introduce me to
it? Something that explains what it is, how to begin using it, etc,
etc? From Visual Studio .NET (2002) I found the references. From VS
.NET 2003 I found no such references. Or maybe I'm missing it?|||We may pursue the SMO option (research on the topic pending). Back to
our original query though... Are there any practical ways to address
the above scenario? Short of assuming that the code must be good
syntactically or it wouldn't have been applied to the syscomments
table. If that is true, then any tokens which fall outside the scope of
available SQL tokens are probably invalid and belong to the comment.
Then we're looking for the first token which appears with a '@.' and
which is followed by a valid type token? (Thinking out loud...)|||<quote>
Please forgive my ignorance, the only reference I see to SMO is in the
MS SOAP toolkit. Is there a primer section that could introduce me to
it? Something that explains what it is, how to begin using it, etc,
etc? From Visual Studio .NET (2002) I found the references. From VS
.NET 2003 I found no such references. Or maybe I'm missing it?
</quote>
For all,
http://msdn2.microsoft.com/en-us/library/ms162169.aspx|||Parsing ad-hoc text is a real pain, even when limited to the header.
Personally, I wouldn't even go there, given the SMO alternative. Consider
cases like:
CREATE PROC MyProc
--@.MyParm1,
@.MyParm2 int = 1,
@.MyParm3 varchar(10) = '@.MyParm4 int',
@.MyParm5 int = 1, @.MyParm6 int = 1 --@.MyParam7 int
AS
...
Hope this helps.
Dan Guzman
SQL Server MVP
"Mike" <mwpowellnm@.comcast.net> wrote in message
news:1133363064.039670.317640@.g14g2000cwa.googlegroups.com...
> We may pursue the SMO option (research on the topic pending). Back to
> our original query though... Are there any practical ways to address
> the above scenario? Short of assuming that the code must be good
> syntactically or it wouldn't have been applied to the syscomments
> table. If that is true, then any tokens which fall outside the scope of
> available SQL tokens are probably invalid and belong to the comment.
> Then we're looking for the first token which appears with a '@.' and
> which is followed by a valid type token? (Thinking out loud...)
>|||As you've probably discovered by now, .Net Framework 2.0 requirement implies
that you'll need to develop using Visual Studio 2005 or at least the 2.0
framework SDK.
Hope this helps.
Dan Guzman
SQL Server MVP
"Mike" <mwpowellnm@.comcast.net> wrote in message
news:1133362835.430233.58550@.g47g2000cwa.googlegroups.com...
> Please forgive my ignorance, the only reference I see to SMO is in the
> MS SOAP toolkit. Is there a primer section that could introduce me to
> it? Something that explains what it is, how to begin using it, etc,
> etc? From Visual Studio .NET (2002) I found the references. From VS
> .NET 2003 I found no such references. Or maybe I'm missing it?
>

extracting SP header information

Greetings,
We have a business requirement to somehow extract the SP header from
syscomments where available. This is done from a COM+ component using
ADO in order to verify whether SP arguments are specified correctly
from a client application, primarily during integration testing. We
know to use sp_helptext, but there is a slight issue...
Parsing around comments is not a problem using block (/* ... */)
commenting style, however single line (-- ...) comments may pose a
problem. It appears as though syscomments spans such comment lines
across table rows. So we end up with something like this:
...
-- blah blah blah (exceeds 255 characters)
blah blah blah (remaining comment
...
This could present some challenges. Is there a safe (and sane) method
of determining when this is the case and making the appropriate
adjustments to the COM+ code?
If we can get past this "little" issue then I am fairly confident we
can parse the remainder of the SP header for the desired argument
information.
Any insight anyone can offer wouldb e much appreciated.
Thanks,
Michael PowellParsing syscomments text seems a bit of a kluge to me. If all you are
interested in is parameter names and data types, it would probably be better
to query INFORMATION_SCHEMA.PARAMETERS.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Mike" <mwpowellnm@.comcast.net> wrote in message
news:1133291509.605075.241180@.f14g2000cwb.googlegroups.com...
> Greetings,
> We have a business requirement to somehow extract the SP header from
> syscomments where available. This is done from a COM+ component using
> ADO in order to verify whether SP arguments are specified correctly
> from a client application, primarily during integration testing. We
> know to use sp_helptext, but there is a slight issue...
> Parsing around comments is not a problem using block (/* ... */)
> commenting style, however single line (-- ...) comments may pose a
> problem. It appears as though syscomments spans such comment lines
> across table rows. So we end up with something like this:
> ...
> -- blah blah blah (exceeds 255 characters)
> blah blah blah (remaining comment
> ...
> This could present some challenges. Is there a safe (and sane) method
> of determining when this is the case and making the appropriate
> adjustments to the COM+ code?
> If we can get past this "little" issue then I am fairly confident we
> can parse the remainder of the SP header for the desired argument
> information.
> Any insight anyone can offer wouldb e much appreciated.
> Thanks,
> Michael Powell
>|||Wow, you are correct. This is about as direct a route as one can expect
querying for parameter information. One thing, however, how do we get
at information such as the default arguments? This doesn't appear to be
available from INFORMATION_SCHEMA.PARAMETERS?|||Aside from parsing the proc header, you can use SMO to get stored procedure
default parameters. SMO is a .Net-based API introduced in SQL 2005 and
version 2.0 of the .Net framework so it needs to be called from managed
code. If your existing COM component is strictly unmanaged, you might find
it easier to wrap the needed SMO stuff in a separate assembly so that you
invoke it using COM interop.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Mike" <mwpowellnm@.comcast.net> wrote in message
news:1133327307.157086.42280@.g47g2000cwa.googlegroups.com...
> Wow, you are correct. This is about as direct a route as one can expect
> querying for parameter information. One thing, however, how do we get
> at information such as the default arguments? This doesn't appear to be
> available from INFORMATION_SCHEMA.PARAMETERS?
>|||Please forgive my ignorance, the only reference I see to SMO is in the
MS SOAP toolkit. Is there a primer section that could introduce me to
it? Something that explains what it is, how to begin using it, etc,
etc? From Visual Studio .NET (2002) I found the references. From VS
.NET 2003 I found no such references. Or maybe I'm missing it?|||We may pursue the SMO option (research on the topic pending). Back to
our original query though... Are there any practical ways to address
the above scenario? Short of assuming that the code must be good
syntactically or it wouldn't have been applied to the syscomments
table. If that is true, then any tokens which fall outside the scope of
available SQL tokens are probably invalid and belong to the comment.
Then we're looking for the first token which appears with a '@.' and
which is followed by a valid type token? (Thinking out loud...)|||<quote>
Please forgive my ignorance, the only reference I see to SMO is in the
MS SOAP toolkit. Is there a primer section that could introduce me to
it? Something that explains what it is, how to begin using it, etc,
etc? From Visual Studio .NET (2002) I found the references. From VS
.NET 2003 I found no such references. Or maybe I'm missing it?
</quote>
For all,
http://msdn2.microsoft.com/en-us/library/ms162169.aspx|||Parsing ad-hoc text is a real pain, even when limited to the header.
Personally, I wouldn't even go there, given the SMO alternative. Consider
cases like:
CREATE PROC MyProc
--@.MyParm1,
@.MyParm2 int = 1,
@.MyParm3 varchar(10) = '@.MyParm4 int',
@.MyParm5 int = 1, @.MyParm6 int = 1 --@.MyParam7 int
AS
...
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Mike" <mwpowellnm@.comcast.net> wrote in message
news:1133363064.039670.317640@.g14g2000cwa.googlegroups.com...
> We may pursue the SMO option (research on the topic pending). Back to
> our original query though... Are there any practical ways to address
> the above scenario? Short of assuming that the code must be good
> syntactically or it wouldn't have been applied to the syscomments
> table. If that is true, then any tokens which fall outside the scope of
> available SQL tokens are probably invalid and belong to the comment.
> Then we're looking for the first token which appears with a '@.' and
> which is followed by a valid type token? (Thinking out loud...)
>|||As you've probably discovered by now, .Net Framework 2.0 requirement implies
that you'll need to develop using Visual Studio 2005 or at least the 2.0
framework SDK.
Hope this helps.
Dan Guzman
SQL Server MVP
"Mike" <mwpowellnm@.comcast.net> wrote in message
news:1133362835.430233.58550@.g47g2000cwa.googlegroups.com...
> Please forgive my ignorance, the only reference I see to SMO is in the
> MS SOAP toolkit. Is there a primer section that could introduce me to
> it? Something that explains what it is, how to begin using it, etc,
> etc? From Visual Studio .NET (2002) I found the references. From VS
> .NET 2003 I found no such references. Or maybe I'm missing it?
>