is there a way to get the disk space occupied by certain rows?
Thank You.
Regards,
A Friend.
SELECT DATALENGTH(ColA) + DATALENGTH(ColB)
From SomeTable
Where Conditionhere
Jens k. Suessmeyer.
http://www.sqlserver2005.de
is there a way to get the disk space occupied by certain rows?
Thank You.
Regards,
A Friend.
Jens k. Suessmeyer.
http://www.sqlserver2005.de
I have a need to filter out certain rows from my data stream. I cannot apply the filter against the source data using my DataReader component, due to some constraints in the source system. Therefore, I must filter the data out after it enters my datastream (trust me on this part).
I have created a data flow that uses the Conditional Split transformation to do this. I created one condition that matches the rows I want to discard. I then connected the Default output stream to my target table. I have simply left the "discard" output disconnected. This appear to do what I want.
My question is: is it OK to leave outputs disconnected in this fashion? It isn't really apparent when viewing the package that the conditional split is discarding rows. Is there a better way to handle this situation? For now I've just added an annotation to the package that describes what is happening.
Thanks for any help
You can use a rowcount transform to make it more 'evident'. That offers the extra benefit of getting the number of rows you discarded; which comes handy for auditing proposes.
There is a 3rd party adapter here that you may want to look as well(i have not used it):
http://www.sqlis.com/56.aspx
|||Yes, you have implemented that perfectly. The only thing I would add is to hook your "filtered" rows up to a Row Count transformation. This will do two things. One, it will let you see that records are going down that flow when debugging. Two it will let you capture the number of rows that went through there in a variable so that you can log it later if you wish.|||As the other guys have said, you have done this in exactly the right way.
I disagree with Phil slightly though (sorry Phil ). I wouldn't bother connecting the dangling output to a rowcount component. This will simply make the data-flow do some unnecassary work. If you DO want to count the number of filtered rows then sure, use a rowcount component - although you can still determine the number of filtered out rows with introducing an additional component by substracting the number of output rows from the number of input rows. These two values are available by logging the OnPipelineRowsSent event.
-Jamie
|||
Jamie Thomson wrote:
If you DO want to count the number of filtered rows then sure, use a rowcount component - although you can still determine the number of filtered out rows with introducing an additional component by substracting the number of output rows from the number of input rows. These two values are available by logging the OnPipelineRowsSent event.
-Jamie
Good idea! How easy is it then to capture that and use it in auditing from a control flow task?|||
Phil Brammer wrote:
Jamie Thomson wrote: If you DO want to count the number of filtered rows then sure, use a rowcount component - although you can still determine the number of filtered out rows with introducing an additional component by substracting the number of output rows from the number of input rows. These two values are available by logging the OnPipelineRowsSent event.
-Jamie
Good idea! How easy is it then to capture that and use it in auditing from a control flow task?
You can get hold of it in the eventhandler. You'd have to parse it out of the message but that's no biggie.
Not as easy as rowcount though. Options...always options!
-Jamie
|||It's amazing how deep you can get in SSIS... Many dark corners yet unexplored!
Hi guys, is it possible to disable database generate scripts for certain users? I would like to restrict it for security purposes while they able to get into the db and their role like the db owner. Hope can any assistance from you guys. Thanks a lot.
Best Regards,
Hans
You can't do it directly; but there is a workaround there.
1. Add the user in Master database
2. Select the db_denydatareader & db_denydatawriter role
3. Deny execute permission of the sp_helptext & etc.. for the given user
|||Thx for the reply Manivannan.D.Sekaran, however it seems not working at all.|||If you don't want your users to have access to the definitions of your Stored Procs, Views, Triggers etc... then you could always re-create the procs with the WITH ENCRYPTION option - just ensure that you store copies of the original scripts in a source control database.
Chris
||||||Thx for the reply,Chris. However, I just wish to the developer unable to generate the db scripts or table scripts for preventing the db structure bring out from the office.|||
Hans1982 wrote:
Thx for the reply Manivannan.D.Sekaran, however it seems not working at all. I wish to create a login for developer that able modify things within the db but cant backup/restore db, generate the whole db scripts and unable to execute 'Script table as' feature.
I can't think of away of doing this other than taking SSMS away from the developers, which would obviously be counter-productive. I guess you could always write your own version of SSMS if this is a big issue for you.
The problem is that the 'Script table as' option directly queries system tables and views that are essential to the running of SQL Server and SSMS. Although you can deny permissions on these objects, doing so is likely to have wide implications.
Why do you need to restrict access to the 'Script table as' functionality?
Chris
|||For preventing the db structure bring out from the office.|||Any developer who has enough knowledge of SQL Server's system tables and views would be able to generate their own scripts to reconstruct the structure without using 'Script As'.
Perhaps you need to look at ways of preventing people from copying / emailing script files from work PCs. Even then there's nothing to stop someone printing out a database diagram and taking it home, or even resorting to copying the structure using more traditional techniques, such as pen and paper.
If your database schema is of such high value then maybe you should address (at least) the above issues and add confidentiality clauses into your developers' contracts. Either that or simply don't allow the people you don't trust to work on your databases.
Chris
|||I see. I guess that's the only solution for that issue because it seems no way to disable the SMO. Thanks for the good advice, Chris. Have a nice day.
Best Regards,
Hans
Display date,Sql server,Sql