I am running a simple query like
SELECT *
FROM [LyncConversationDetail].[dbo].[MessageDetails]
WHERE ProjectId = '13'
but I am not getting more than 10,000 rows as a result, not sure what am I missing here as I don't have much knowledge in this. Is there any SQL Server setting for max row count? Or is it dependent on something else?
Try to check how many rows is in Your table.
SELECT count(*)
FROM [LyncConversationDetail].[dbo].[MessageDetails] where ProjectId='13'
Related
Ive got a question about row level security in MSSQL 2016 Standard Edition.
The issue is;
We are currently using MSSQL 2012 SE. We have tables that has
sensitive data in it and we have users who should reach those tables
in a limited access.
We are now preventing them to select all the data in those tables by
giving them a stored procedure to select that table so that procedure
gives the result of the TOP 5 of the query (by setting ROWCOUNT = 5
in the SP) . So these users always can select top 5 rows of the
query.
As we are upgrading MSSQL from 2012 to 2016 SE this week, i wonder if
we can do this process by using Row Level Security ? I have
researched about it, and i couldn't find a way to set ROWCOUNT = 5 in
the inline table valued function.
I just need to prevent some users to select all the table even though
they want to. And i also dont want them to select the table by using
a stored procedure or something like that.
Is there a better solution to do so in sql 2016 ?
Can anyone help me on this ? Thanks in advance.
I have a very simple query that is driving me absolutely nuts.
Here's the situation:
I have two database servers.
One is an old SQL Server 2000 (VM), very minimal resources.
The other is a very large SQL Server 2005 enterprise cluster with an absolutely ridiculous amount of resources available.
I have a small portion of a larger query that executes in 3 seconds and returns 50,000+ rows of data on SQL Server 2000
This same small query takes upwards of 15 minutes to return 1000 rows on SQL Server 2005
The database I'm working with is a mirror image on these two servers. Same tables, same data in tables, same indexes on tables, etc.
I've tried creating different indexes on the SQL Server 2005 tables, defragged all the indexes that exist, updated table statistics, etc. Nothing has been able to make this query run faster on SQL Server 2005. Currently nothing else is running against the SQL Server 2005 server, and our DBAs assure me it's not a configuration issue or anything to do with feature deprecation between SQL Server 2000 and SQL Server 2005.
The query is below:
SELECT (CASE
WHEN TeamMember.ID IN (SELECT DISTINCT ProjMgrID FROM ProjMgr)
THEN 'Yes'
ELSE 'No'
END) AS OnProjAsMgr
FROM TeamMember
So return a distinct list of all the ProjMgrs, and if the TeamMember is on that list then assign "Yes" to the OnProjAsMgr value.
I'm a total SQL newbie, and this is code written by a predecessor. I don't know if there's a better way to write it, but I cannot figure out why it runs great on SQL Server 2000 but completely implodes on SQL Server 2005.
DISTINCT causes a sort, and IN causes the entire query to be evaluated. How does this version work:
SELECT OnProjAsMgr = CASE WHEN EXISTS
(SELECT 1 FROM dbo.ProjMgr WHERE ProjMgrID = TeamMember.ID)
THEN 'Yes'
ELSE 'No'
END
FROM dbo.TeamMember;
If that fares no better then I suspect indexes are missing and no query will perform well without them.
I don't know about "better" way, but here's a different way that you can try:
SELECT ... other fields you want ...,
CASE WHEN ProjMgr.ProjMgrID IS NULL
THEN 'No'
ELSE 'Yes'
END AS OnProjAsMgr
FROM TeamMember
LEFT
OUTER
JOIN ProjMgr
ON ProjMgr.ProjMgrID = TeamMember.ID
;
Notes:
On some DBMSes, this will perform much better than your query, but I don't know whether it would perform better on SQL Server 2005, given that your query already works fine on SQL Server 2000. I think you'll just have to try it.
Your query uses SELECT DISTINCT ProjMgrID FROM ProjMgr. If that is actually different from SELECT ProjMgrID FROM ProjMgr — that is, if there are actually duplicate values of ProjMgrID in ProjMgr — then the above query is not exactly equivalent to yours, since it will give a separate record for each duplicate. You might have to add a GROUP BY clause in that case.
For that matter, if SELECT DISTINCT ProjMgrID FROM ProjMgr is equivalent to SELECT ProjMgrID FROM ProjMgr for your data, as I suspect, then it also might be worth removing the DISTINCT, since that might affect the optimizer as well.
SELECT (
CASE WHEN P.ID IS NULL THEN 'No' ELSE 'Yes' END
) AS OnProjAsMgr
FROM TeamMember AS T
LEFT OUTER JOIN ProjMgr AS P ON T.ID=P.ID
I have a Linq query which is working fine but i have noticed when i use take keyword with that query it does not return the same top selected records.
When i saw the Sql profiler query they are totally same excepts just top keyword in that what may be the problem. One more thing i have noticed is when i give a no greater then records in database it works fine with take as well.
I am attaching the query and records attachment
and when I apply top 10 in this query it shows this records
What could be the problem im using Sql Server 2008 R2.
Using TOP keyword without ordering does not guarantee repeatability of resultset.
From here
If a SELECT statement that includes TOP also has an ORDER BY clause,
the rows to be returned are selected from the ordered result set. The
whole result set is built in the specified order and the top n rows in
the ordered result set are returned.
Try forcing the query to order the records by using ORDER BY (or orderby in linq).
The default ordering may differ, try explicitly ordering by a column.
I create a query: Select * from HR_Tsalary where month='3' and year ='2010' the result is 473 records and I found 2 duplicate record, then I create another query to find duplicate record only: SELECT Emp_No, COUNT() FROM HR_Tsalary WHERE year = '10' AND month = '3'GROUP BY Emp_No HAVING COUNT() > 1 the result is zero record from client side (thru Visual Basic Adodb code). But when I use same query from server the result is 2 records. Is there any different when create a query between from server side and client side?
You could start SQL Server Profiler then run your VB code, and see the exact query that's hitting the database and make sure it is what you're expecting.
-Krip
SQL server profile is always open also I identified that from client side some functions are working such as select, order by but some functions are not working such as group by, sum, count, having
When I worked on the Zend Framework's database component, we tried to abstract the functionality of the LIMIT clause supported by MySQL, PostgreSQL, and SQLite. That is, creating a query could be done this way:
$select = $db->select();
$select->from('mytable');
$select->order('somecolumn');
$select->limit(10, 20);
When the database supports LIMIT, this produces an SQL query like the following:
SELECT * FROM mytable ORDER BY somecolumn LIMIT 10, 20
This was more complex for brands of database that don't support LIMIT (that clause is not part of the standard SQL language, by the way). If you can generate row numbers, make the whole query a derived table, and in the outer query use BETWEEN. This was the solution for Oracle and IBM DB2. Microsoft SQL Server 2005 has a similar row-number function, so one can write the query this way:
SELECT z2.*
FROM (
SELECT ROW_NUMBER OVER(ORDER BY id) AS zend_db_rownum, z1.*
FROM ( ...original SQL query... ) z1
) z2
WHERE z2.zend_db_rownum BETWEEN #offset+1 AND #offset+#count;
However, Microsoft SQL Server 2000 doesn't have the ROW_NUMBER() function.
So my question is, can you come up with a way to emulate the LIMIT functionality in Microsoft SQL Server 2000, solely using SQL? Without using cursors or T-SQL or a stored procedure. It has to support both arguments for LIMIT, both count and offset. Solutions using a temporary table are also not acceptable.
Edit:
The most common solution for MS SQL Server 2000 seems to be like the one below, for example to get rows 50 through 75:
SELECT TOP 25 *
FROM (
SELECT TOP 75 *
FROM table
ORDER BY BY field ASC
) a
ORDER BY field DESC;
However, this doesn't work if the total result set is, say 60 rows. The inner query returns 60 rows because that's in the top 75. Then the outer query returns rows 35-60, which doesn't fit in the desired "page" of 50-75. Basically, this solution works unless you need the last "page" of a result set that doesn't happen to be a multiple of the page size.
Edit:
Another solution works better, but only if you can assume the result set includes a column that is unique:
SELECT TOP n *
FROM tablename
WHERE key NOT IN (
SELECT TOP x key
FROM tablename
ORDER BY key
);
Conclusion:
No general-purpose solution seems to exist for emulating LIMIT in MS SQL Server 2000. A good solution exists if you can use the ROW_NUMBER() function in MS SQL Server 2005.
Here is another solution which only works in Sql Server 2005 and newer because it uses the except statement. But I share it anyway.
If you want to get the records 50 - 75 write:
select * from (
SELECT top 75 COL1, COL2
FROM MYTABLE order by COL3
) as foo
except
select * from (
SELECT top 50 COL1, COL2
FROM MYTABLE order by COL3
) as bar
SELECT TOP n *
FROM tablename
WHERE key NOT IN (
SELECT TOP x key
FROM tablename
ORDER BY key
DESC
);
When you need LIMIT only, ms sql has the equivalent TOP keyword, so that is clear.
When you need LIMIT with OFFSET, you can try some hacks like previously described, but they all add some overhead, i.e. for ordering one way and then the other, or the expencive NOT IN operation.
I think all those cascades are not needed. The cleanest solution in my oppinion would be just use TOP without offset on the SQL side, and then seek to the required starting record with the appropriate client method, like mssql_data_seek in php. While this isn't a pure SQL solution, I think it is the best one because it doesn't add any overhead (the skipped-over records will not be transferred on the network when you seek past them, if that is what worries you).
I would try to implement this in my ORM as it is pretty simple there. If it really needs to be in SQL Server then I would look at the code generated by linq to sql for the following linq to sql statement and go from there. The MSFT engineer who implemented that code was part of the SQL team for many years and knew what he was doing.
var result = myDataContext.mytable.Skip(pageIndex * pageSize).Take(pageSize)