Embadded code in VB.Net

Hello everyone!
We have a small problem with one report ,that include VB code.
The code - Vb function ,that connect to Active Directory and return some
value
from DB
When I run my report in local machine I got correctly results,
when I deploy the report - I have #Error.
In the custom code I did all necessary references .
Please help me and sorry for my EnglishOn the server, by default, all code has execute-only privileges. You need to
create a custom assembly to hold this code and then grant addition
permissions to it. See
http://msdn.microsoft.com/SQL/sqlwarehouse/ReportingServices/default.aspx?pull=/library/en-us/dnsql2k/html/dngrfcodeaccesssecurityinsqlserver2000reportingservices.asp.
--
Brian Welcker
Group Program Manager
Microsoft SQL Server
This posting is provided "AS IS" with no warranties, and confers no rights.
"Vikont" <Vikont@.discussions.microsoft.com> wrote in message
news:2328E5C7-7A39-45D4-953E-A79B9B2FF1FD@.microsoft.com...
> Hello everyone!
> We have a small problem with one report ,that include VB code.
> The code - Vb function ,that connect to Active Directory and return some
> value
> from DB
> When I run my report in local machine I got correctly results,
> when I deploy the report - I have #Error.
> In the custom code I did all necessary references .
> Please help me and sorry for my English|||Did you follow the guidance in
http://msdn.microsoft.com/SQL/sqlwarehouse/ReportingServices/default.aspx?pull=/library/en-us/dnsql2k/html/dngrfcodeaccesssecurityinsqlserver2000reportingservices.asp?
--
Brian Welcker
Group Program Manager
Microsoft SQL Server
This posting is provided "AS IS" with no warranties, and confers no rights.
"Vikont" <Vikont@.discussions.microsoft.com> wrote in message
news:2328E5C7-7A39-45D4-953E-A79B9B2FF1FD@.microsoft.com...
> Hello everyone!
> We have a small problem with one report ,that include VB code.
> The code - Vb function ,that connect to Active Directory and return some
> value
> from DB
> When I run my report in local machine I got correctly results,
> when I deploy the report - I have #Error.
> In the custom code I did all necessary references .
> Please help me and sorry for my English

EM - Open table - Return Top... -1000

Is there a way to change the Open table - Return Top... -1000 default
to something like 10. It should return only 10 by default? Any registry
keys?<geethacharan@.gmail.com> wrote in message
news:1097703679.181878.189490@.f14g2000cwb.googlegr oups.com...
> Is there a way to change the Open table - Return Top... -1000 default
> to something like 10. It should return only 10 by default? Any registry
> keys?

It doesn't look like it - there's no obvious option or registry key that
changes this.

Simon

eliminate the Return charactor in a column

Hi,
We have a column defined as ntext for a column and we need to transfer this
column to oralce platform. Before transferring, we convert the data to
varchar. Some of data content "RETURN" charactor, and it caused issue for
providing report or printing.
Please suggest a way to eliminate the "RETURN" charactor in this column and
we can keep all the data in the nice order. Thanks.
Best Regards,
Lynnhttp://www.aspfaq.com/2445
"Lynn" <Lynn@.discussions.microsoft.com> wrote in message
news:3F6073C5-BF70-4DFA-BAE0-DD4EFA30A8AA@.microsoft.com...
> Hi,
> We have a column defined as ntext for a column and we need to transfer
> this
> column to oralce platform. Before transferring, we convert the data to
> varchar. Some of data content "RETURN" charactor, and it caused issue for
> providing report or printing.
> Please suggest a way to eliminate the "RETURN" charactor in this column
> and
> we can keep all the data in the nice order. Thanks.
> --
> Best Regards,
> Lynn

Eliminate Rows with Redundant Columns

I would like my query to return the KeyID from row 4 but from only one of
the first 3 rows where the address data is redundant. Since use of the key
eliminates the DISTINCT operator, is there another method?
DECLARE @.tAddress TABLE (KeyID int, Address varchar(10), City varchar(10),
ST varchar(2))
INSERT @.tAddress
SELECT 1, '100 Main', 'Boston', 'MA'
UNION ALL
SELECT 2, '100 Main', 'Boston', 'MA'
UNION ALL
SELECT 3, '100 Main', 'Boston', 'MA'
UNION ALL
SELECT 4, '200 Main', 'Boston', 'MA'
Thanks!SELECT Address, City, ST, MIN(KeyID)
FROM @.tAddress
GROUP BY Address, City, ST
Or, if you really only wanted the ID column:
SELECT MIN(KeyID)
FROM @.tAddress
GROUP BY Address, City, ST
Roy Harvey
Beacon Falls, CT
On Wed, 14 Jun 2006 09:47:32 -0700, "Mike Harbinger"
<MikeH@.Cybervillage.net> wrote:

>I would like my query to return the KeyID from row 4 but from only one of
>the first 3 rows where the address data is redundant. Since use of the key
>eliminates the DISTINCT operator, is there another method?
>DECLARE @.tAddress TABLE (KeyID int, Address varchar(10), City varchar(10),
>ST varchar(2))
>INSERT @.tAddress
>SELECT 1, '100 Main', 'Boston', 'MA'
>UNION ALL
>SELECT 2, '100 Main', 'Boston', 'MA'
>UNION ALL
>SELECT 3, '100 Main', 'Boston', 'MA'
>UNION ALL
>SELECT 4, '200 Main', 'Boston', 'MA'
>Thanks!
>|||Simple and elegant; I should have seen that. Many thanks Roy!
"Roy Harvey" <roy_harvey@.snet.net> wrote in message
news:csf092h8em6sabqjre5jf7jsbmrhroovtc@.
4ax.com...
> SELECT Address, City, ST, MIN(KeyID)
> FROM @.tAddress
> GROUP BY Address, City, ST
> Or, if you really only wanted the ID column:
> SELECT MIN(KeyID)
> FROM @.tAddress
> GROUP BY Address, City, ST
> Roy Harvey
> Beacon Falls, CT
> On Wed, 14 Jun 2006 09:47:32 -0700, "Mike Harbinger"
> <MikeH@.Cybervillage.net> wrote:
>

efficient select

It seems I should be able to do 1 select and both return that
recordset and be able to set a variable from that recordset.

eg.
Declare @.refid int
Select t.* from mytable as t --return the recordset
Set @.refid = t.refid

the above doesn't work-how can I do it without making a second trip to
the database?
Thanks,
Rick"Rick" <rick@.abasoftware.com> wrote in message
news:28d7cbb9.0409140717.9d794dc@.posting.google.co m...
> It seems I should be able to do 1 select and both return that
> recordset and be able to set a variable from that recordset.
> eg.
> Declare @.refid int
> Select t.* from mytable as t --return the recordset
> Set @.refid = t.refid
> the above doesn't work-how can I do it without making a second trip to
> the database?
> Thanks,
> Rick

select @.refid = t.refid from mytable where <your condition|||"strider5" <strider5@.s.zm.com> wrote in message
news:ci73p5$l4a$1@.domitilla.aioe.org...
> "Rick" <rick@.abasoftware.com> wrote in message
> news:28d7cbb9.0409140717.9d794dc@.posting.google.co m...
> > It seems I should be able to do 1 select and both return that
> > recordset and be able to set a variable from that recordset.
> > eg.
> > Declare @.refid int
> > Select t.* from mytable as t --return the recordset
> > Set @.refid = t.refid
> > the above doesn't work-how can I do it without making a second trip to
> > the database?
> > Thanks,
> > Rick
> select @.refid = t.refid from mytable where <your condition>

should be :
select @.refid = t.refid from mytable as t where <your condition|||Rick (rick@.abasoftware.com) writes:
> It seems I should be able to do 1 select and both return that
> recordset and be able to set a variable from that recordset.
> eg.
> Declare @.refid int
> Select t.* from mytable as t --return the recordset
> Set @.refid = t.refid
> the above doesn't work-how can I do it without making a second trip to
> the database?

You can't both return a result set and set a variable in the same
SELECT statement.

In many cases, it is not very ineffecient to access the table twice,
as the second read will be from cache. But if the search conditions
calls for a longer execution time, one possibility is to buffer the
result in a temp table or table variable, and then access that table
twice.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

Efficiency Question

In terms of the time a query would take to return, is there any difference
if a table has, say, 200 records and 100 columns vs. 100 records and 200
columns? Ultimately, I'm trying to figure out if speed needs to be a
consideration in determining whether to orient a new table horizontally or
vertically.
Thanks,
James
Size of the data returned rather than number of columns and rows is a more
relevant statistic but overall performance depends on other factors (such as
indexing) that are at least as important.

> Ultimately, I'm trying to figure out if speed needs to be a
> consideration in determining whether to orient a new table horizontally or
> vertically.
I would suggest that you're going about your table design the wrong way!
Normalize your design in (at minimum) Third Normal Form to start with. Once
you have done that you can test performance and make any optimizations
necesssary. Correct design doesn't normally involve choosing between
"horizontal" and "vertical" orientations of data.
David Portas
SQL Server MVP
|||Well, the design of this table is relatively simple and straightforward...if
we had even reasonable hardware. I've been having to design tables around
poor hardware performance...trying to keep as little data as possible in any
given table, in order to prevent a meltdown.
The design was fine until the hardware hit the proverbial wall and
everything started crashing when even a moderate size query was run. So
instead of sinking a few thousand dollars into new hardware, they sank a few
thousand dollars into man hours, trying to solve the problem with intellect.
So far it's been relatively unsuccessful.
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:DJOdnT3qqPhoSmbdRVn-ow@.giganews.com...
> Size of the data returned rather than number of columns and rows is a more
> relevant statistic but overall performance depends on other factors (such
as[vbcol=seagreen]
> indexing) that are at least as important.
or
> I would suggest that you're going about your table design the wrong way!
> Normalize your design in (at minimum) Third Normal Form to start with.
Once
> you have done that you can test performance and make any optimizations
> necesssary. Correct design doesn't normally involve choosing between
> "horizontal" and "vertical" orientations of data.
> --
> David Portas
> SQL Server MVP
> --
>
|||> In terms of the time a query would take to return, is there any difference
> if a table has, say, 200 records and 100 columns vs. 100 records and 200
> columns? Ultimately, I'm trying to figure out if speed needs to be a
> consideration in determining whether to orient a new table horizontally or
> vertically.
Your table design should be driven by normalizing the entities you are
trying to represent, not optimizing number of columns vs. number of rows.
If performance is a problem due to hardware constraints, fix the hardware.
Anything you do in the context of the above will be a bandaid at best, and
will only serve to yield *different* performance problems down the line,
IMHO.
http://www.aspfaq.com/
(Reverse address to reply.)

Efficiency Question

In terms of the time a query would take to return, is there any difference
if a table has, say, 200 records and 100 columns vs. 100 records and 200
columns? Ultimately, I'm trying to figure out if speed needs to be a
consideration in determining whether to orient a new table horizontally or
vertically.
Thanks,
JamesSize of the data returned rather than number of columns and rows is a more
relevant statistic but overall performance depends on other factors (such as
indexing) that are at least as important.
> Ultimately, I'm trying to figure out if speed needs to be a
> consideration in determining whether to orient a new table horizontally or
> vertically.
I would suggest that you're going about your table design the wrong way!
Normalize your design in (at minimum) Third Normal Form to start with. Once
you have done that you can test performance and make any optimizations
necesssary. Correct design doesn't normally involve choosing between
"horizontal" and "vertical" orientations of data.
--
David Portas
SQL Server MVP
--|||Well, the design of this table is relatively simple and straightforward...if
we had even reasonable hardware. I've been having to design tables around
poor hardware performance...trying to keep as little data as possible in any
given table, in order to prevent a meltdown.
The design was fine until the hardware hit the proverbial wall and
everything started crashing when even a moderate size query was run. So
instead of sinking a few thousand dollars into new hardware, they sank a few
thousand dollars into man hours, trying to solve the problem with intellect.
So far it's been relatively unsuccessful.
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:DJOdnT3qqPhoSmbdRVn-ow@.giganews.com...
> Size of the data returned rather than number of columns and rows is a more
> relevant statistic but overall performance depends on other factors (such
as
> indexing) that are at least as important.
> > Ultimately, I'm trying to figure out if speed needs to be a
> > consideration in determining whether to orient a new table horizontally
or
> > vertically.
> I would suggest that you're going about your table design the wrong way!
> Normalize your design in (at minimum) Third Normal Form to start with.
Once
> you have done that you can test performance and make any optimizations
> necesssary. Correct design doesn't normally involve choosing between
> "horizontal" and "vertical" orientations of data.
> --
> David Portas
> SQL Server MVP
> --
>|||> In terms of the time a query would take to return, is there any difference
> if a table has, say, 200 records and 100 columns vs. 100 records and 200
> columns? Ultimately, I'm trying to figure out if speed needs to be a
> consideration in determining whether to orient a new table horizontally or
> vertically.
Your table design should be driven by normalizing the entities you are
trying to represent, not optimizing number of columns vs. number of rows.
If performance is a problem due to hardware constraints, fix the hardware.
Anything you do in the context of the above will be a bandaid at best, and
will only serve to yield *different* performance problems down the line,
IMHO.
--
http://www.aspfaq.com/
(Reverse address to reply.)

Efficiency Question

In terms of the time a query would take to return, is there any difference
if a table has, say, 200 records and 100 columns vs. 100 records and 200
columns? Ultimately, I'm trying to figure out if speed needs to be a
consideration in determining whether to orient a new table horizontally or
vertically.
Thanks,
JamesSize of the data returned rather than number of columns and rows is a more
relevant statistic but overall performance depends on other factors (such as
indexing) that are at least as important.

> Ultimately, I'm trying to figure out if speed needs to be a
> consideration in determining whether to orient a new table horizontally or
> vertically.
I would suggest that you're going about your table design the wrong way!
Normalize your design in (at minimum) Third Normal Form to start with. Once
you have done that you can test performance and make any optimizations
necesssary. Correct design doesn't normally involve choosing between
"horizontal" and "vertical" orientations of data.
David Portas
SQL Server MVP
--|||Well, the design of this table is relatively simple and straightforward...if
we had even reasonable hardware. I've been having to design tables around
poor hardware performance...trying to keep as little data as possible in any
given table, in order to prevent a meltdown.
The design was fine until the hardware hit the proverbial wall and
everything started crashing when even a moderate size query was run. So
instead of sinking a few thousand dollars into new hardware, they sank a few
thousand dollars into man hours, trying to solve the problem with intellect.
So far it's been relatively unsuccessful.
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:DJOdnT3qqPhoSmbdRVn-ow@.giganews.com...
> Size of the data returned rather than number of columns and rows is a more
> relevant statistic but overall performance depends on other factors (such
as
> indexing) that are at least as important.
>
or[vbcol=seagreen]
> I would suggest that you're going about your table design the wrong way!
> Normalize your design in (at minimum) Third Normal Form to start with.
Once
> you have done that you can test performance and make any optimizations
> necesssary. Correct design doesn't normally involve choosing between
> "horizontal" and "vertical" orientations of data.
> --
> David Portas
> SQL Server MVP
> --
>|||> In terms of the time a query would take to return, is there any difference
> if a table has, say, 200 records and 100 columns vs. 100 records and 200
> columns? Ultimately, I'm trying to figure out if speed needs to be a
> consideration in determining whether to orient a new table horizontally or
> vertically.
Your table design should be driven by normalizing the entities you are
trying to represent, not optimizing number of columns vs. number of rows.
If performance is a problem due to hardware constraints, fix the hardware.
Anything you do in the context of the above will be a bandaid at best, and
will only serve to yield *different* performance problems down the line,
IMHO.
http://www.aspfaq.com/
(Reverse address to reply.)