For exporting data from Datagridview to Excel , connect database and load data from database to Datagridview and create a new excel file and write the data from Datagridview to Excel file .
The DBA is not going to have time to scrutinize every change made to a stored procedure. Learning to do basic tuning might save you from reworking code late in the game.
Performance tuning is not easy and there aren’t any silver bullets, but you can go a surprisingly long way with a few basic guidelines.
Database Optimization for Developers:
- If your application stops working suddenly, it may not be a database issue. For example, maybe you have a network problem. Investigate a bit before you accuse a DBA!
- Even if you’re a ninja SQL data modeler, ask a DBA to help you with your relational diagram. They have a lot to share and offer.
- DBAs don’t like rapid changes. This is natural: they need to analyze the database as a whole and examine the impact of any changes from all angles. A simple change in a column can take a week to be implemented—but that’s because an error could materialize as huge losses for the company. Be patient!
- Do not ask SQL DBAs to make data changes in a production environment. If you want access to the production database, you have to be responsible for all your own changes.
Database Optimization for SQL Server DBAs:
- If you don’t like people asking you about the database, give them a real-time status panel. Developers are always suspicious of a database’s status, and such a panel could save everyone time and energy.
- Help developers in a test/quality assurance environment. Make it easy to simulate a production server with simple tests on real-world data. This will be a significant time-saver for others as well as yourself.
- Developers spend all day on systems with frequently-changed business logic. Try to understand this world being more flexible, and be able to break some rules in a critical moment.
- SQL databases evolve. The day will come when you have to migrate your data to a new version. Developers count on significant new functionality with each new version. Instead of refusing to accept their changes, plan ahead and be ready for the migration.
If you are looking to remove the server header from your IIS, you will need to install URL Scan to be able to go through the settings.
UrlScan is a security tool used to restrict types of HTTP requests that IIS will process. It is a simple tool which is very helpful in blocking harmful requests to the server. It seemingly supports only IIS 5.1, IIS 6.0, and IIS 7.0 on Windows Vista and Windows Server 2008. It has been deprecated since IIS 7.5 and IIS 8. It is said that Microsoft has included the features of UrlScan in request filtering option for IIS 7.5 and IIS 8. But it definitely is not a match for the simplicity of UrlScan. Today I am going to show you how to configure UrlScan in IIS 7.5 and IIS8. (IIS 7.5 is available in Windows server 2008 R2 and IIS 8 is available in Windows Server 2012 and Windows 8 ).
Install the URLScan in your machine. Please follow the following link for that
When you are trying to install it on a new server, you might get an error saying:
IIS Metabase is required to install Microsoft UrlScan Filter v3.1
To fix this issue:
- Open Web Platform Installer
- Search for metabase and install “IIS: IIS 6 Metabase Compatibility”
- Then, select IIS ISAPI Filters. (ISAPI filters may already be installed in IIS 7.5 )
- Click on Install. You are shown a review of components you selected to install. Click on I accept.
- The components are installed and will show you a Finish screen. Click on Finish.
- To check installation, go in IIS and click on your server node.
- Click on ISAPI filters under IIS
After installing URLScan, open the URLScan.ini file typically located in the %WINDIR%\System32\Inetsrv\URLscan folder. After opening it, search for the key RemoveServerHeader . By default it is set to 0, but to remove the Server header, change the value to 1.
Doing so will remove the Server header Server: Microsoft-IIS/7.5 (8) from the User mode response.
When developing integrations with external services (REST, SOAP), there is often the need to use specific SSL protocols, namely:
- TLS 1.1
- TLS 1.2.
While trying to use those API’s in OutSystems applications, such attempts to integrate may not work, and produce errors like:
- The request was aborted: Could not create SSL/TLS secure channel.
- Unsupported procotol. You need to enable TLS X.X to use this API
(other types of errors may occur, related to the required SSL protocols)
TLS 1.0 is no longer secure. Exploits exist to downgrade a connection based on TLS 1.0 to an older version of the protocol. There is no active exploit affecting all of TLS 1.1, but the downgrade attack works on some versions and installations and academically speaking, TLS 1.1’s hash functions are under threat.
If using an older SSL/TLS protocol revision you could have someone sitting on the line and taking in your data while absolutely nothing about the connection indicated it. A compromised secure connection is no different from an insecure connection, but may give a false sense of security.
The revision and deprecation of protocols is an expected, occasional thing, as encryption techniques improve and processing speeds increase over time. This deprecation and notice is for our customers’ security. Anyone keeping up with the latest developments will already be secure, but those who have not kept up to date could end up using an insecure method.
What is TLS?
Transport Layer Security (TLS) is a protocol that ensures privacy between communicating applications and their users on the Internet. When a server and client communicate, TLS ensures that no third-party may eavesdrop or tamper with any message. TLS is the successor to the Secure Sockets Layer (SSL).
- TLS 1.1 Spec: http://tools.ietf.org/html/rfc4346
- TLS 1.2 Spec: http://tools.ietf.org/html/rfc5246
- Vulnerabilities prompting moving from TLS 1.0/1.1: https://www.globalsign.com/en/blog/poodle-vulnerability-expands-beyond-sslv3-to-tls/
- TLS 1.1 uses a combination of SHA-1 and MD5 by default, whereas TLS 1.2 uses SHA-256. Academically speaking, an attack on TLS 1.1 is sitting somewhere between “will be plausible in a few years” to “actively in-use by nation states.”
In SQL Server, indexes can be a double-edged sword. Sure, they can make queries run faster, but at the same time, their maintenance can have a negative impact. You can improve your server’s overall performance by only maintaining useful indexes – but finding the ones you don’t need can be quite a manual process.
If you see indexes where there are no seeks, scans or lookups, but there are updates this means that SQL Server has not used the index to satisfy a query but still needs to maintain the index.
Remember that the data from these DMVs is reset when SQL Server is restarted, so make sure you have collected data for a long enough period of time to determine which indexes may be good candidates to be dropped.
Run this in SQL Server:
SELECT OBJECT_NAME(S.[OBJECT_ID]) AS [OBJECT NAME], I.[NAME] AS [INDEX NAME], USER_SEEKS, USER_SCANS, USER_LOOKUPS, USER_UPDATES FROM SYS.DM_DB_INDEX_USAGE_STATS AS S INNER JOIN SYS.INDEXES AS I ON I.[OBJECT_ID] = S.[OBJECT_ID] AND I.INDEX_ID = S.INDEX_ID WHERE OBJECTPROPERTY(S.[OBJECT_ID],'IsUserTable') = 1 AND S.database_id = DB_ID()
Here we can see seeks, scans, lookups and updates.
The seeks refer to how many times an index seek occurred for that index. A seek is the fastest way to access the data, so this is good.
The scans refers to how many times an index scan occurred for that index. A scan is when multiple rows of data had to be searched to find the data. Scans are something you want to try to avoid.
The lookups refer to how many times the query required data to be pulled from the clustered index or the heap (does not have a clustered index). Lookups are also something you want to try to avoid.
The updates refers to how many times the index was updated due to data changes which should correspond to the first query above.
To find the ones that can be safely removed, run this:
SELECT OBJECT_NAME(S.[OBJECT_ID]) AS [OBJECT NAME], I.[NAME] AS [INDEX NAME], USER_SEEKS, USER_SCANS, USER_LOOKUPS, USER_UPDATES FROM SYS.DM_DB_INDEX_USAGE_STATS AS S INNER JOIN SYS.INDEXES AS I ON I.[OBJECT_ID] = S.[OBJECT_ID] AND I.INDEX_ID = S.INDEX_ID WHERE OBJECTPROPERTY(S.[OBJECT_ID],'IsUserTable') = 1 AND OBJECT_NAME(S.[OBJECT_ID]) = '[your table name]' AND S.database_id = DB_ID() AND (USER_SEEKS = 0 AND USER_SCANS =0 AND USER_LOOKUPS=0)
You can then delete the unused indexes.