credentials of the user datasource

Hi,

I'd like to programme the execution of a report through the execution property option. However, when I try to do it a message error appears related to credentials of the datasource.

The present action is impossible to complete, because the credentials of the user datasource needed to execute this report are not stored on report server database.

I've tried all possible combinations.

Any idea?

Thanks.

Please set user name and password of the user datasource

following is the sample code to set it.

Microsoft.Reporting.WebForms.DataSourceCredentials[] crd = new Microsoft.Reporting.WebForms.DataSourceCredentials[1];

crd[0] = new Microsoft.Reporting.WebForms.DataSourceCredentials();

crd[0].Name = "DatasourceName";

crd[0].UserId = User;

crd[0].Password = Pwd;

ReportViewer.ServerReport.SetDataSourceCredentials(crd);

If you are using multiple data sources you need to set credentials for each datasource..

please set datasource credentials after setting report and parameter of the report to report viewer..

|||

By "programme the execution of a report through the execution property option" you don't by any chance mean "I want to set up a snapshot or scheduled report through the Executioin panel of the Properties tab of the Report Manager"?

If this is what you mean, then the message means exactly what it says: the datasource has to have its credentials stored with it (whether it is a shared datasource or one embedded in the report).

If the datasource is set up to run with the credentials of the logged-in user, then it can't be queried when there is no logged-in user (such as when you want a snapshot to execute). Doesn't that make sense?

So... how is the data set up for your report? And with what type(s) of credentials is it accessed?

>L<

Creation name for ComponentMetadata

Hi,
I want to get the TaskHost.CreationName equivalent on a IDTSComponentMetaData90 object. Basically the CreationName property returns me the string used to create an instance of the DtsContainer object. (DTS.Pipeline for example). How do I get an equivalent on a data flow component. (ComponentMetadata object). There is a ObjectType property which returns a enum of type DTSObjectType but I want a string representation of the enum.

Thanks,
-SuriI figured out a work around. The CreationName is the ProgId and the ComponentClassId on the ComponentMetadata object gives me the classid. I do a little Pinvoke on ole32.dll to use ProgIDFromCLSID.

let me know if there is a better way.

Thanks|||I'm not sure what you are doing, but you may want to look at the Microsoft.SqlServer.Dts.Runtime.Application object and the PipelineComponentInfos.

Each PipelineComponentInfo has a CreationName.

Creating table with Identity property

Hi, if I want to create a table with IDENTITY(1,1) property and do not
state any PK or simular constraints. Does that IDENTITY serve as a
unique identifier to that tabel or is it nessecary to implement some
constraints as well'
I'm new to all this with SQL and trying to learn about it!
Ex:
CREATE TABLE Employee
{
EMPID int NOT NULL IDENTITY(1,1),
EMPNAME varchar(8) NOT NULL,
EMPADDRESS varchar(30) NULL
}zekevarg skrev:

> Hi, if I want to create a table with IDENTITY(1,1) property and do not
> state any PK or simular constraints. Does that IDENTITY serve as a
> unique identifier to that tabel or is it nessecary to implement some
> constraints as well'
>
The IDENTITY property does not impose any constraints on its own, you
can do a search on Google for IDENTITY in this news group and you'll
get a lot to read :)
/impslayer, aka Birger Johansson|||zekevarg wrote:
> Hi, if I want to create a table with IDENTITY(1,1) property and do not
> state any PK or simular constraints. Does that IDENTITY serve as a
> unique identifier to that tabel or is it nessecary to implement some
> constraints as well'
> I'm new to all this with SQL and trying to learn about it!
> Ex:
> CREATE TABLE Employee
> {
> EMPID int NOT NULL IDENTITY(1,1),
> EMPNAME varchar(8) NOT NULL,
> EMPADDRESS varchar(30) NULL
> }
I answered this in the thread you started yesterday:
http://groups.google.co.uk/group/mi...372625141cc0196
You should always add a UNIQUE or PRIMARY KEY constraint to an IDENTITY
column if you want it to be unique. Typically IDENTITY will be declared
as the primary key and used as the referenced column in foreign key
constraints.
However, even where you do put a key constraint on an IDENTITY column
it shouldn't be the ONLY key of a table. That's because IDENTITY won't
prevent duplicate data in the table. Also it isn't a good idea to
expose IDENTITY columns to end users (one reason being that you can't
ever update the column) - therefore if IDENTITY is the only key your
users will not have a useable key at all.
That's my opinion. It's true that many people will have differing
opinions on this topic. I would urge you however to read and understand
relational design theory and principles such as normalization rather
than just listen to advice in newsgroups (including my own). You can
make better decisions and implement better solutions if you understand
the fundamentals rather than basing your knowledge only on examples and
tips.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||>> if I want to create a table with IDENTITY(1,1) property and do not state
any PK or simular constraints. <<
Then **by definition** it is not a table. A key must be made up of a
unique subset of the atributes of the entity, not the internal state of
a counter in the hardware that stores the data.
No, it is an exposed physical locator -- like a record number was in a
1950's mag tape file system. Ask yourself if the IDENTITY would be
different if you inserted the same data in a different order (yes!0,
then ask yourself if you part numbers would stay the same irregardless
of the order of insertion (yes, of course!). That is because a part
number is a key and an IDENTITY is not.
There is no "as well" on this. You will never use an IDENTITY in a
properly designed RDBMS.
It is a whole different model of data and it will take you awhile to
get it. Think abstract, no physical; think sets and not sequences;
think declarative, not procedural (i.e. whar, not how) and think
parallel, not sequential.|||FWIW, I thought you should know that "irregardless" is not a proper
word in the english language.
check out: http://en.wiktionary.org/wiki/irregardless
We all expect perfection from you, as you do from us.|||On 16 Mar 2006 07:25:20 -0800, "JeffB" <jeff.bolton@.citigatehudson.com>
wrote:
in <1142522719.973281.149580@.j52g2000cwj.googlegroups.com>

>FWIW, I thought you should know that "irregardless" is not a proper
>word in the english language.
>check out: http://en.wiktionary.org/wiki/irregardless
>We all expect perfection from you, as you do from us.
While I agree with your pedantic point, regretfully the word
irregardless has crept into the language by virtue of its use. Ack!
As you can see in the article you've pointed to, its status has already
risen from not-a-word to non-standard. Another 10-15 years and it
~will~ be a word. :-(
This posting is provided "AS IS" with no warranties, no guarantees, and no c
onferred rights.
Stefan Berglund|||In some parts of the country, "irregardless" is the word used when folks
want to show off using a 50 cent word.
that's scary.
-Paul
"Stefan Berglund" <sorry.no.koolaid@.for.me> wrote in message
news:i08j12te8qbvmc0i57jlhq90jh5jg05d7f@.
4ax.com...
> On 16 Mar 2006 07:25:20 -0800, "JeffB" <jeff.bolton@.citigatehudson.com>
> wrote:
> in <1142522719.973281.149580@.j52g2000cwj.googlegroups.com>
>
> While I agree with your pedantic point, regretfully the word
> irregardless has crept into the language by virtue of its use. Ack!
> As you can see in the article you've pointed to, its status has already
> risen from not-a-word to non-standard. Another 10-15 years and it
> ~will~ be a word. :-(
> --
> This posting is provided "AS IS" with no warranties, no guarantees, and no
> conferred rights.
> Stefan Berglund|||>> Think abstract, no physical
I like the white board as much as anyone, but just remember that abstract
has never held any actual data. Every data table that has actually had a
practical use has been, and will always be, a physical table. The relational
abstract at some point has to be converted into the physical SQL.
-Paul Nielsen
SQL Server MVP
www.SQLServerBible.com
"--CELKO--" <jcelko212@.earthlink.net> wrote in message
news:1142521746.581278.276740@.u72g2000cwu.googlegroups.com...
> Then **by definition** it is not a table. A key must be made up of a
> unique subset of the atributes of the entity, not the internal state of
> a counter in the hardware that stores the data.
>
> No, it is an exposed physical locator -- like a record number was in a
> 1950's mag tape file system. Ask yourself if the IDENTITY would be
> different if you inserted the same data in a different order (yes!0,
> then ask yourself if you part numbers would stay the same irregardless
> of the order of insertion (yes, of course!). That is because a part
> number is a key and an IDENTITY is not.
>
> There is no "as well" on this. You will never use an IDENTITY in a
> properly designed RDBMS.
>
> It is a whole different model of data and it will take you awhile to
> get it. Think abstract, no physical; think sets and not sequences;
> think declarative, not procedural (i.e. whar, not how) and think
> parallel, not sequential.
>|||Paul Nielsen (MVP) wrote:
> I like the white board as much as anyone, but just remember that abstract
> has never held any actual data. Every data table that has actually had a
> practical use has been, and will always be, a physical table. The relation
al
> abstract at some point has to be converted into the physical SQL.
A table is part of the logical data model, not the physical one. DATA
has to have a physical representation in storage of course, but the
principle of Physical Data Independence means that there is absolutely
no reason why a table itself has to have a direct physical counterpart.
The only requirement is that the DBMS can construct the results of
queries using persisted data and metadata.
SQL Server's data structures are such that (loosely speaking) you can
point to a set of pages in files and say "that's a table" but the same
isn't true in all other SQL databases (column-based storage is one
alternative for example).
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--

Creating property get and set clauses based on a table or sp

Is there a way to automatically (wizard?) to create the get and set clauses of a class based on a SQL table or sp? I need to wrap a number of tables and sp into classes to use them in an ASP.net application and it's rather tedious to do type each one.

What I would like is something that I could point at a table and have it create a class and the get and set properties. I could save that as a class and use it in the program.
eg. Point to a table people.
Results would be
Class People
property FirstName()
get

set

...

Aim.You can create a strong typed data set.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpcongeneratingstronglytypeddataset.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconusingannotationswithtypeddataset.asp

It will generate the class based on a xml schema, and you can easily build a schema by drag and dropping your table on the xml scheman designer.|||Thanks for the reply, I appreciate your time. However, I am not sure that it is what I want. Maybe I am missing the point.

I want to create a class based on a table. The class would have a local variable and a property get/set clause for each field in the table.
eg if the table were
FirstName
LastName
Middle Initial

I would end up with a class that looked something like

class Name
dim fname as string
dim lname as string
dim mi as string

Public Property FirstName() As String
Get
Return fname
End Get
Set(ByVal Value As String)
fname = Value
End Set
End Property

Public Property LastName() As String
Get
Return lname
End Get
Set(ByVal Value As String)
lname = Value
End Set
End Property
Public Property MiddleInitial() As String
Get
Return mi
End Get
Set(ByVal Value As String)
mi = Value
End Set
End Property

end class

If anyone knows how I can do this I would appreciate a hint or two.

Aim.|||You can do it yourself if you set your query analyzer output to text mode with space separators.

declare @.TABLE_NAME='Name'
print 'Class ' + @.TABLE_NAME + '
'
select 'dim _'+COLUMN_NAME+' as'
, CASE DATA_TYPE WHEN 'int' THEN 'Integer' ELSE 'string' END
from INFORMATION_SCHEMA.COLUMNS
where TABLE_NAME=@.TABLE_NAME
select 'Public Property '+COLUMN_NAME+' As',
CASE DATA_TYPE WHEN 'int' THEN 'Integer' ELSE 'String' END, '
Get
Return _'+COLUMN_NAME+'
End Get
Set(ByVal Value As',
CASE DATA_TYPE WHEN 'int' THEN 'Integer' ELSE 'String' END,
')
_'+COLUMN_NAME+' = Value
End Set
End Property
'
from INFORMATION_SCHEMA.COLUMNS
where TABLE_NAME=@.TABLE_NAME
print 'End Class'

|||Thanks for that. It's a cute solution. Maybe I can package that and make my own wizard.

Cheers

Aim.