Sunday, March 25, 2012
Best Query Strategy
The problem is the number of parts that need to be queried at one time; 10 t
o
100 parts. That would make for a very messy WHERE clause. I am wonder if
there is a better strategy?
If it matters, I am using VB.NET.
Thanks
--Rob
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200510/1Robin,
Are the parts PART OF a larger organizational unit i.e., a project or a
company or...?
HTH
Jerry
"Robin H via droptable.com" <u4108@.uwe> wrote in message
news:5655fd7d2e20a@.uwe...
>I am faced with the need to query the price of parts from a 3 table join.
> The problem is the number of parts that need to be queried at one time; 10
> to
> 100 parts. That would make for a very messy WHERE clause. I am wonder if
> there is a better strategy?
> If it matters, I am using VB.NET.
> Thanks
> --Rob
>
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200510/1|||Robin,
Is it possible you could do a VIEW for this as long as the query is not
dynamic?
Shahryar
Robin H via droptable.com wrote:
>I am faced with the need to query the price of parts from a 3 table join.
>The problem is the number of parts that need to be queried at one time; 10
to
>100 parts. That would make for a very messy WHERE clause. I am wonder if
>there is a better strategy?
>If it matters, I am using VB.NET.
>Thanks
>--Rob
>
>
Shahryar G. Hashemi | Sr. DBA Consultant
InfoSpace, Inc.
601 108th Ave NE | Suite 1200 | Bellevue, WA 98004 USA
Mobile +1 206.459.6203 | Office +1 425.201.8853 | Fax +1 425.201.6150
shashem@.infospace.com | www.infospaceinc.com
This e-mail and any attachments may contain confidential information that is
legally privileged. The information is solely for the use of the intended
recipient(s); any disclosure, copying, distribution, or other use of this in
formation is strictly prohi
bited. If you have received this e-mail in error, please notify the sender
by return e-mail and delete this message. Thank you.
Best Query Strategy
The problem is the number of parts that need to be queried at one time; 10 to
100 parts. That would make for a very messy WHERE clause. I am wonder if
there is a better strategy?
If it matters, I am using VB.NET.
Thanks
--Rob
Message posted via droptable.com
http://www.droptable.com/Uwe/Forums...erver/200510/1
Robin,
Are the parts PART OF a larger organizational unit i.e., a project or a
company or...?
HTH
Jerry
"Robin H via droptable.com" <u4108@.uwe> wrote in message
news:5655fd7d2e20a@.uwe...
>I am faced with the need to query the price of parts from a 3 table join.
> The problem is the number of parts that need to be queried at one time; 10
> to
> 100 parts. That would make for a very messy WHERE clause. I am wonder if
> there is a better strategy?
> If it matters, I am using VB.NET.
> Thanks
> --Rob
>
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forums...erver/200510/1
|||Robin,
Is it possible you could do a VIEW for this as long as the query is not
dynamic?
Shahryar
Robin H via droptable.com wrote:
>I am faced with the need to query the price of parts from a 3 table join.
>The problem is the number of parts that need to be queried at one time; 10 to
>100 parts. That would make for a very messy WHERE clause. I am wonder if
>there is a better strategy?
>If it matters, I am using VB.NET.
>Thanks
>--Rob
>
>
Shahryar G. Hashemi | Sr. DBA Consultant
InfoSpace, Inc.
601 108th Ave NE | Suite 1200 | Bellevue, WA 98004 USA
Mobile +1 206.459.6203 | Office +1 425.201.8853 | Fax +1 425.201.6150
shashem@.infospace.com | www.infospaceinc.com
This e-mail and any attachments may contain confidential information that is legally privileged. The information is solely for the use of the intended recipient(s); any disclosure, copying, distribution, or other use of this information is strictly prohi
bited. If you have received this e-mail in error, please notify the sender by return e-mail and delete this message. Thank you.
Best Query Strategy
The problem is the number of parts that need to be queried at one time; 10 to
100 parts. That would make for a very messy WHERE clause. I am wonder if
there is a better strategy?
If it matters, I am using VB.NET.
Thanks
--Rob
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200510/1Robin,
Are the parts PART OF a larger organizational unit i.e., a project or a
company or...?
HTH
Jerry
"Robin H via SQLMonster.com" <u4108@.uwe> wrote in message
news:5655fd7d2e20a@.uwe...
>I am faced with the need to query the price of parts from a 3 table join.
> The problem is the number of parts that need to be queried at one time; 10
> to
> 100 parts. That would make for a very messy WHERE clause. I am wonder if
> there is a better strategy?
> If it matters, I am using VB.NET.
> Thanks
> --Rob
>
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200510/1|||Robin,
Is it possible you could do a VIEW for this as long as the query is not
dynamic?
Shahryar
Robin H via SQLMonster.com wrote:
>I am faced with the need to query the price of parts from a 3 table join.
>The problem is the number of parts that need to be queried at one time; 10 to
>100 parts. That would make for a very messy WHERE clause. I am wonder if
>there is a better strategy?
>If it matters, I am using VB.NET.
>Thanks
>--Rob
>
>
Shahryar G. Hashemi | Sr. DBA Consultant
InfoSpace, Inc.
601 108th Ave NE | Suite 1200 | Bellevue, WA 98004 USA
Mobile +1 206.459.6203 | Office +1 425.201.8853 | Fax +1 425.201.6150
shashem@.infospace.com | www.infospaceinc.com
This e-mail and any attachments may contain confidential information that is legally privileged. The information is solely for the use of the intended recipient(s); any disclosure, copying, distribution, or other use of this information is strictly prohibited. If you have received this e-mail in error, please notify the sender by return e-mail and delete this message. Thank you.
Sunday, March 11, 2012
Best practice for formulating a default value for a queried parameters
In general, what is the most appropriate way to specify a "data driven" default for a report parameter. Seems to me like options are:
1. construct an expression which operates on one of the existing report datasets (possibly the same data set used to populate the defaults dropdown)
2. construct a new dataset which returns a single value which is the desired default
what's the "normal" approach?
For example, I have an MDX dataset which contains the list of dates for which data is available. There is generally some data available for today, but normally the user is interested in the most recent day with data prior to today.
So which would be the better option out of the two above (or a third option if I'm missing something!) to tell my parameter to set itself to:
"The most recent day prior to today for which data exists".
I would think that an expression off of the dataset used to populate the available dates would be appropriate. It doesn't require additional trips for data and decreases the amount of information returned. Of course, this is just an opinion...![]()
that sounds like it makes sense - on the other hand the querying language available through expressions is highly reduced (as far as i can see) compared to MDX (or sql).
So maybe the best approach is:
1. Don't use an expression at all, just reference the dataset if all you want it the first value.
2. Failing that, use and expression if it's simple
3. failing that, use a completely new dataset
Best practice for formulating a default value for a queried parameters
In general, what is the most appropriate way to specify a "data driven" default for a report parameter. Seems to me like options are:
1. construct an expression which operates on one of the existing report datasets (possibly the same data set used to populate the defaults dropdown)
2. construct a new dataset which returns a single value which is the desired default
what's the "normal" approach?
For example, I have an MDX dataset which contains the list of dates for which data is available. There is generally some data available for today, but normally the user is interested in the most recent day with data prior to today.
So which would be the better option out of the two above (or a third option if I'm missing something!) to tell my parameter to set itself to:
"The most recent day prior to today for which data exists".
I would think that an expression off of the dataset used to populate the available dates would be appropriate. It doesn't require additional trips for data and decreases the amount of information returned. Of course, this is just an opinion...![]()
that sounds like it makes sense - on the other hand the querying language available through expressions is highly reduced (as far as i can see) compared to MDX (or sql).
So maybe the best approach is:
1. Don't use an expression at all, just reference the dataset if all you want it the first value.
2. Failing that, use and expression if it's simple
3. failing that, use a completely new dataset
Friday, February 24, 2012
Best approach to encrypt data?
I want to encrypt certain data like password, ssn, credit card info etc before saving in database. Also, this encrypted data can be queried using standard SQL statements like:
select * from users where userid=454 and password = 'encrypted data'
The mechanism to encrypt data could be in a .net application. The code that does encryption/decryption should also be protected so that it doesnt work if it falls in wrong hands.
Can anyone suggest what would be the best way to accomplish above?
thanks,
dapi
You can start with the following links
http://www.microsoft.com/technet/prodtechnol/sql/2005/sqlencryption.mspx
http://articles.techrepublic.com.com/5100-22-5083541.html
Hope this helps
|||I would suggest reading "Writing Secure Code", Chapter 6. It has a number of examples of how to encrypt data on a Windows platform, and where people make common mistakes. The book is fairly cheap ($0.10 per page) and probably available at the library. I understand C# has a rather extensive crypto library, but knowing how and why is probably better than just "plugging and chugging".
Hope that helps,
John