Basic Question about password and logon command

I have running SQL queries all day and have been getting tired of selecting the DATA SOURCE NAME and then having to type in the appropriate password. What can I add to my SQL command to do this for me?
Thanks for the help!
NormDo you mean like a connect line in your script?|||Originally posted by exdter
Do you mean like a connect line in your script?

Yes, exactly|||Is this what you mean?
The first line of your script should be
conn[ect] user/password/database
The problem with this is that your password won't be encrypted, so someone can see it.
I hope this helps.|||Originally posted by exdter
Is this what you mean?
The first line of your script should be
conn[ect] user/password/database
The problem with this is that your password won't be encrypted, so someone can see it.
I hope this helps.

Forgive my ignorance but I don't think I asked for the right thing.

Here's what I'm looking at....

I'm in Access and I run an SQL query such as:

select COUNT(*) from employee_data where title = 'Programmer'

and the next thing you know is a window pops up where I need to click on the "Machine Data Source" tab and then the appropriate "Data Source Name" which then has me type in my password.

Thanks for the help.

Norm|||Oh, sorry. I can't help with that one.
I don't know Access.

Basic query question

Hi,
I have a basic query question and hope that someone can clarify for me.
2 queries...
#1
\\\
SELECT *
FROM
Table1 AS A
INNER JOIN Table2 AS B ON
B.Column1 = A.Column1 AND
B.Column2 = A.Column2
///
#2
\\\
SELECT *
FROM
Table1 AS A, Table2 AS B
WHERE
B.Column1 = A.Column1 AND
B.Column2 = A.Column2
///
I suppose I will get the same result among these 2 queries, I just wonder is
there any performance different between these 2 queries? Any opinion which
one is better?
Thanks in advance.it will really give you the same result
but as a matter of standard
i suggest you use the first one.
performance wise i dont know.
its just that the first one is my preferred
choice
<hr>
MCP #2324787
"Kent" wrote:

> Hi,
> I have a basic query question and hope that someone can clarify for me.
> 2 queries...
> #1
> \\\
> SELECT *
> FROM
> Table1 AS A
> INNER JOIN Table2 AS B ON
> B.Column1 = A.Column1 AND
> B.Column2 = A.Column2
> ///
> #2
> \\\
> SELECT *
> FROM
> Table1 AS A, Table2 AS B
> WHERE
> B.Column1 = A.Column1 AND
> B.Column2 = A.Column2
> ///
> I suppose I will get the same result among these 2 queries, I just wonder
is
> there any performance different between these 2 queries? Any opinion whic
h
> one is better?
> Thanks in advance.|||AFAIK, there will be no performance difference between these two
particular queries; the optimizer should recognize them as being the
same and generate an identical execution plan for them (something which
you can easily test in Query Analyzer).
I prefer the JOIN syntax because it
a) is easier to read (to me), and
b) allows you to perform more complex joins. You can easily join three
tables with an INNER JOIN between two of those tables, and an OUTER
JOIN with the last table.
HTH,
Stu|||Kent,
This issue is a old issue and I think that our gurus here could answer you
with guarantee. From my own point of view it's the same although I prefer th
e
first one.
Regards,
"Jose G. de Jesus Jr MCP, MCDBA" wrote:
> it will really give you the same result
> but as a matter of standard
> i suggest you use the first one.
> performance wise i dont know.
> its just that the first one is my preferred
> choice
> --
>
> <hr>
> MCP #2324787
>
> "Kent" wrote:
>|||Kent
No, should not be any differences bettwen two queries. See an execution
plan to make sure.
"Kent" <Kent@.discussions.microsoft.com> wrote in message
news:EBE53BFA-BCF0-437A-847C-548B447FBDD5@.microsoft.com...
> Hi,
> I have a basic query question and hope that someone can clarify for me.
> 2 queries...
> #1
> \\\
> SELECT *
> FROM
> Table1 AS A
> INNER JOIN Table2 AS B ON
> B.Column1 = A.Column1 AND
> B.Column2 = A.Column2
> ///
> #2
> \\\
> SELECT *
> FROM
> Table1 AS A, Table2 AS B
> WHERE
> B.Column1 = A.Column1 AND
> B.Column2 = A.Column2
> ///
> I suppose I will get the same result among these 2 queries, I just wonder
> is
> there any performance different between these 2 queries? Any opinion
> which
> one is better?
> Thanks in advance.|||The optimizer will recognize these doing the same thing and optimize them th
e same way. The first is
preferred and the more modern syntax.
Outer joins is another story, though... In short, don't use the old ( *= ) s
yntax.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Kent" <Kent@.discussions.microsoft.com> wrote in message
news:EBE53BFA-BCF0-437A-847C-548B447FBDD5@.microsoft.com...
> Hi,
> I have a basic query question and hope that someone can clarify for me.
> 2 queries...
> #1
> \\\
> SELECT *
> FROM
> Table1 AS A
> INNER JOIN Table2 AS B ON
> B.Column1 = A.Column1 AND
> B.Column2 = A.Column2
> ///
> #2
> \\\
> SELECT *
> FROM
> Table1 AS A, Table2 AS B
> WHERE
> B.Column1 = A.Column1 AND
> B.Column2 = A.Column2
> ///
> I suppose I will get the same result among these 2 queries, I just wonder
is
> there any performance different between these 2 queries? Any opinion whic
h
> one is better?
> Thanks in advance.|||Ya, they are the same in Execution Plan.
I think the first one is more neat when I get to join more tables.
Thanks all for help. :)
"Tibor Karaszi" wrote:

> The optimizer will recognize these doing the same thing and optimize them
the same way. The first is
> preferred and the more modern syntax.
> Outer joins is another story, though... In short, don't use the old ( *= )
syntax.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "Kent" <Kent@.discussions.microsoft.com> wrote in message
> news:EBE53BFA-BCF0-437A-847C-548B447FBDD5@.microsoft.com...
>

bad query plan when using parameterised queries on partitioned vie

Recently I found rather a nasty consequence by using parameterised queries o
n
a partitioned view.
I have a .net app that sends parameterised queries to SQL Server 2000. SQL
Server obliges by caching the query plan to increase efficiency of subsequen
t
queries.
In my case the query is running against a partitioned view, partitioned by a
date constraint.
A query is run when the cache is cleared and the query optimiser correctly
creates a query plan specifying only the correct partition and ignoring the
other partitions, so far so good…
Subsequent queries run fine and use the cached query plan until we get a
query where the date range selected now relates to a different underlying
partition – blam, full table scan against all partitions! As you might gue
ss
the query execution times blow out by several orders of magnitude! It seems
it tries to use a bad query plan from the cache and when it realises it can
t
get the data it needs it is not smart enough to re-evaluate the query plan
properly.
Currently I am forcing a recompile on these guys go make sure the cached
plan is not used as it obviously cannot be trusted! This workaround does the
trick but I’m wondering if anyone has experienced something similar before
?
Or is there a better way to deal with this? It seems to me to be in fact a
bug as the optimiser should handle this a lot better than it does.
Thoughts anyone?
Cheers,
Chrissounds like parameter sniffing problem. Sure there are ways better than
WITH RECOMPILE. Search for "parameter sniffing" in this group or google.