Showing posts with label particular. Show all posts
Showing posts with label particular. Show all posts

Tuesday, March 27, 2012

Binding SQL to an IP

I've got SQL 2k5 on a Win2k3 box. I'm trying to find information or a how to on how to set up SQL to only respond to requests on a particular IP

Can anybody point me in the right direction or explain how?

v

HI,

AFAIK you cannot bin SQL Server to respond to particular IP address but you can trick with firewall settings.

HTH

Hemantgiri S. Goswami

binding COUNT

hi guys,

i want to count the number of times a particular data occurs in a table and display that data in a listbox

initially i planned to count the number of occurrences and bind that number to a variable for further manipulation but i have no idea how to do the binding part

how do i solve this?

thanx

Are you trying to update a db column that contains the count? If you're trying to do that, you could use a trigger or daily/nightly processing to do this based on how often you want it updated, how frequently the table is accessed, etc. If you're trying to do it in code, you could just set your variable equal to "select count ... where..." and mess with it in the code.

Thanks,
Sam Lester (MSFT)

|||

thanx sam!

Saturday, February 25, 2012

Better way to filter dimension members?

I have a dimension hierarchy that has several thousand members (it's a geographical one). We often times want to answer questions for a particular city or zip code in the hierarchy - has anyone found a better filtration mechanism in either BI studio's OLAP browser or Excel 2007? Basically, I'd love to just type "Seattle" or "Seattle, WA" and have it choose the Seattle geographical member (instead of navigating the full hierarchy to select it).

Better design practice in case of having hierarchy containing many members is pretty simple, but is not often simple to implement. Unfortunately there arent that many alternatives.

Anyhow. You need to try and create additional levels in your hierarchy so your users can navigate down to the subset of members. For example Customer dimension should have Customer hierarchy where you get to particular customer navigating through Customer Country, Customer State, Customer City levels.

If you are unable to come up with such nice hierarchy, you should try and build another attribute in the dimension based on exactly the same column but set the DiscretizationMethod property for it, such it becomes a grouping level. You add this additional attribute on top of your original one to create artificial way of navigating. It is bit clugy but without a way of navigating to subset of members you are stuck with displaying nundreds or thousand of members for user and that is not a very good idea.

HTH

Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

Thursday, February 16, 2012

best way to optimize certain tables

I have a SqlServer 2000 running 7 databases. One in particular is slower
than the rest specificaly on certain tables. It seems the problem comes
from the volume of data, but I don't think 3000 lines can be considered a
big table. I have indexes on the principal keys, but it did not help.
thank you
Hi,
Identify the stored procedures , Queries taking more time / CPU. Use the
profiler tuning templace to identify this. After that save the
file as a workload table or file. Use the workload file as the input file
for index tning wizard.
I feel that this slow responce is due to the lack of proper indexes.
You could also use the Execution plans to tune your queries.
Thanks
Hari
SQL Server MVP
"Fernand St-Georges" <fernand.st-georges@.videotron.ca> wrote in message
news:Ethwe.79344$Yu4.927653@.wagner.videotron.net.. .
>I have a SqlServer 2000 running 7 databases. One in particular is slower
> than the rest specificaly on certain tables. It seems the problem comes
> from the volume of data, but I don't think 3000 lines can be considered a
> big table. I have indexes on the principal keys, but it did not help.
> thank you
>
|||Tables are not slow. They are just data containers.
Queries can be slow, if they are not written properly, or when the
underlying tables are not properly indexed. You could follow Hari's
advice to analyse where and why they are slow.
You could also give the Index Tuning Wizard a try.
HTH,
Gert-Jan
Fernand St-Georges wrote:
> I have a SqlServer 2000 running 7 databases. One in particular is slower
> than the rest specificaly on certain tables. It seems the problem comes
> from the volume of data, but I don't think 3000 lines can be considered a
> big table. I have indexes on the principal keys, but it did not help.
> thank you
|||Check the queries and use index tuning wizard.
Are you re-indexing the tables frequently?
Thanks
Ravi
"Fernand St-Georges" wrote:

> I have a SqlServer 2000 running 7 databases. One in particular is slower
> than the rest specificaly on certain tables. It seems the problem comes
> from the volume of data, but I don't think 3000 lines can be considered a
> big table. I have indexes on the principal keys, but it did not help.
> thank you
>
>

best way to optimize certain tables

I have a SqlServer 2000 running 7 databases. One in particular is slower
than the rest specificaly on certain tables. It seems the problem comes
from the volume of data, but I don't think 3000 lines can be considered a
big table. I have indexes on the principal keys, but it did not help.

thank youFernand St-Georges (fernand.st-georges@.videotron.ca) writes:
> I have a SqlServer 2000 running 7 databases. One in particular is slower
> than the rest specificaly on certain tables. It seems the problem comes
> from the volume of data, but I don't think 3000 lines can be considered a
> big table. I have indexes on the principal keys, but it did not help.

3000 rows is indeed a fairly small table. But a weird enough query and
make even that table slow to work with.

You need to find out more of what is going on. One way is to run Profiler,
and capture the SP:StmtCompleted, SQL:StatementCompleted, SP:Completed
and RPC:Completed events with some good filter on Duration, so you can
locate the slow queries. If there are any slow queries. The problem could
be blocking as well.

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

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Please post DDL, so that people do not have to guess what the keys,
constraints, Declarative Referential Integrity, data types, etc. in
your schema are. Sample data is also a good idea, along with clear
specifications. It is very hard to debug code when you do not let us
see it.

best way to optimize certain tables

I have a SqlServer 2000 running 7 databases. One in particular is slower
than the rest specificaly on certain tables. It seems the problem comes
from the volume of data, but I don't think 3000 lines can be considered a
big table. I have indexes on the principal keys, but it did not help.
thank youHi,
Identify the stored procedures , Queries taking more time / CPU. Use the
profiler tuning templace to identify this. After that save the
file as a workload table or file. Use the workload file as the input file
for index tning wizard.
I feel that this slow responce is due to the lack of proper indexes.
You could also use the Execution plans to tune your queries.
Thanks
Hari
SQL Server MVP
"Fernand St-Georges" <fernand.st-georges@.videotron.ca> wrote in message
news:Ethwe.79344$Yu4.927653@.wagner.videotron.net...
>I have a SqlServer 2000 running 7 databases. One in particular is slower
> than the rest specificaly on certain tables. It seems the problem comes
> from the volume of data, but I don't think 3000 lines can be considered a
> big table. I have indexes on the principal keys, but it did not help.
> thank you
>|||Tables are not slow. They are just data containers.
Queries can be slow, if they are not written properly, or when the
underlying tables are not properly indexed. You could follow Hari's
advice to analyse where and why they are slow.
You could also give the Index Tuning Wizard a try.
HTH,
Gert-Jan
Fernand St-Georges wrote:
> I have a SqlServer 2000 running 7 databases. One in particular is slower
> than the rest specificaly on certain tables. It seems the problem comes
> from the volume of data, but I don't think 3000 lines can be considered a
> big table. I have indexes on the principal keys, but it did not help.
> thank you|||Check the queries and use index tuning wizard.
Are you re-indexing the tables frequently?
--
Thanks
Ravi
"Fernand St-Georges" wrote:
> I have a SqlServer 2000 running 7 databases. One in particular is slower
> than the rest specificaly on certain tables. It seems the problem comes
> from the volume of data, but I don't think 3000 lines can be considered a
> big table. I have indexes on the principal keys, but it did not help.
> thank you
>
>

best way to optimize certain tables

I have a SqlServer 2000 running 7 databases. One in particular is slower
than the rest specificaly on certain tables. It seems the problem comes
from the volume of data, but I don't think 3000 lines can be considered a
big table. I have indexes on the principal keys, but it did not help.
thank youHi,
Identify the stored procedures , Queries taking more time / CPU. Use the
profiler tuning templace to identify this. After that save the
file as a workload table or file. Use the workload file as the input file
for index tning wizard.
I feel that this slow responce is due to the lack of proper indexes.
You could also use the Execution plans to tune your queries.
Thanks
Hari
SQL Server MVP
"Fernand St-Georges" <fernand.st-georges@.videotron.ca> wrote in message
news:Ethwe.79344$Yu4.927653@.wagner.videotron.net...
>I have a SqlServer 2000 running 7 databases. One in particular is slower
> than the rest specificaly on certain tables. It seems the problem comes
> from the volume of data, but I don't think 3000 lines can be considered a
> big table. I have indexes on the principal keys, but it did not help.
> thank you
>|||Tables are not slow. They are just data containers.
Queries can be slow, if they are not written properly, or when the
underlying tables are not properly indexed. You could follow Hari's
advice to analyse where and why they are slow.
You could also give the Index Tuning Wizard a try.
HTH,
Gert-Jan
Fernand St-Georges wrote:
> I have a SqlServer 2000 running 7 databases. One in particular is slower
> than the rest specificaly on certain tables. It seems the problem comes
> from the volume of data, but I don't think 3000 lines can be considered a
> big table. I have indexes on the principal keys, but it did not help.
> thank you|||Check the queries and use index tuning wizard.
Are you re-indexing the tables frequently?
Thanks
Ravi
"Fernand St-Georges" wrote:

> I have a SqlServer 2000 running 7 databases. One in particular is slower
> than the rest specificaly on certain tables. It seems the problem comes
> from the volume of data, but I don't think 3000 lines can be considered a
> big table. I have indexes on the principal keys, but it did not help.
> thank you
>
>