The post Seven Reasons Why SSRS is Still a Good Reporting Tool appeared first on SQL Help.

Here are the key points to consider:

• No immediate changes are required until your next renewal period.
• Fabric capacity offers enhanced benefits, including smaller compute SKUs and MACC compatibility.
• Power BI Pro and PPU services will not be impacted.

Get ready for 2025 – explore more about this transition and how it will affect your Power BI experience! See the link below for more information.

Update coming to Power BI Premium licensing

The post Important Update for Power BI Users appeared first on SQL Help.

SELECT 
    dbschemas.[name] as 'Schema',
    dbtables.[name] as 'Table',
    dbindexes.[name] as 'Index',
    indexstats.avg_fragmentation_in_percent
FROM 
    sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) indexstats
    INNER JOIN sys.tables dbtables on dbtables.[object_id] = indexstats.[object_id]
    INNER JOIN sys.schemas dbschemas on dbtables.[schema_id] = dbschemas.[schema_id]
    INNER JOIN sys.indexes dbindexes on dbindexes.[object_id] = indexstats.[object_id]
       AND indexstats.index_id = dbindexes.index_id
WHERE 
    indexstats.database_id = DB_ID()
ORDER BY 
    indexstats.avg_fragmentation_in_percent DESC;

ALTER INDEX [IndexName] ON [SchemaName].[TableName] REORGANIZE;

ALTER INDEX ALL ON [SchemaName].[TableName] REORGANIZE;

ALTER INDEX [IndexName] ON [SchemaName].[TableName] REBUILD;

ALTER INDEX ALL ON [SchemaName].[TableName] REBUILD;

DECLARE @TableName NVARCHAR(128);
DECLARE @IndexName NVARCHAR(128);
DECLARE @SchemaName NVARCHAR(128);
DECLARE @sql NVARCHAR(MAX);

DECLARE IndexCursor CURSOR FOR
SELECT 
    dbschemas.[name] as 'Schema',
    dbtables.[name] as 'Table',
    dbindexes.[name] as 'Index',
    indexstats.avg_fragmentation_in_percent
FROM 
    sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) indexstats
    INNER JOIN sys.tables dbtables on dbtables.[object_id] = indexstats.[object_id]
    INNER JOIN sys.schemas dbschemas on dbtables.[schema_id] = dbschemas.[schema_id]
    INNER JOIN sys.indexes dbindexes on dbindexes.[object_id] = indexstats.[object_id]
       AND indexstats.index_id = dbindexes.index_id
WHERE 
    indexstats.database_id = DB_ID();

OPEN IndexCursor;
FETCH NEXT FROM IndexCursor INTO @SchemaName, @TableName, @IndexName, @Fragmentation;

WHILE @@FETCH_STATUS = 0
BEGIN
    IF @Fragmentation > 30
    BEGIN
        SET @sql = 'ALTER INDEX [' + @IndexName + '] ON [' + @SchemaName + '].[' + @TableName + '] REBUILD';
    END
    ELSE IF @Fragmentation BETWEEN 5 AND 30
    BEGIN
        SET @sql = 'ALTER INDEX [' + @IndexName + '] ON [' + @SchemaName + '].[' + @TableName + '] REORGANIZE';
    END
    
    EXEC sp_executesql @sql;
    
    FETCH NEXT FROM IndexCursor INTO @SchemaName, @TableName, @IndexName, @Fragmentation;
END

CLOSE IndexCursor;
DEALLOCATE IndexCursor;

The post Basic Index Maintenance in SQL Server appeared first on SQL Help.

We have implemented many data warehouses in SQL Server, using SSIS and SQL stored procedures for ETL / ELT.

We’re highly experienced and proficient in T-SQL, stored procedures, triggers, SQL troubleshooting , and using SSIS to create fast, accurate and secure data pipelines.

More recently, we have been involved in Microsoft Power BI and DAX to create compelling reports and dashboards for all sizes of business. As part of this, we have used SSRS to create paginated detail reports.

Other roles include presenting, providing training, and passing on SQL Server / Power BI and DAX skills to other team members.

Our Data Warehousing Experience

For ETL/ ELT, we have written many, many SSIS and SQL scripts, including advanced data transformations, database change tracking, slowly changing dimensions (SCDs) custom scripts in VB and C#, connecting to disparate OLEDB and ODBC data sources, error tracking and deployment.

What are the Challenges when designing and implementing a Data Warehouse?

Designing a data warehouse requires a solid understanding of the organization’s data requirements, as well as the data sources that are available. The following are the key considerations in designing a data warehouse:

Data Sources
Determine the types of data sources that need to be included in the data warehouse, including transactional systems, legacy systems, and cloud-based systems. The data sources need to be integrated into the data warehouse to ensure that the data is consistent, accurate, and up-to-date.

Data Modeling
Define the data structure for the data warehouse, including the relationships between tables, data elements, and attributes. The data model should also take into account the organization’s data requirements, including the types of reports and analysis that will be performed.

ETL (Extract, Transform, Load) or ELT (Extract, Load, Transform)
Develop an ETL or ELT process to extract data from the sources, transform the data into a format that is suitable for the data warehouse, and load the data into the data warehouse. This process should be automated and regularly scheduled to ensure that the data in the data warehouse is up-to-date.

Data Quality
Ensure the data quality of the data in the data warehouse by implementing data validation and data cleansing rules. This helps to ensure that the data is accurate and consistent, and minimizes the risk of incorrect data being used for analysis and reporting.

Performance
Ensure that the data warehouse is optimized for performance, including the indexing of data, the use of summary tables, and the use of materialized views. This helps to ensure that the data can be retrieved quickly and efficiently for analysis and reporting.

Security
Implement security measures to ensure that the data in the data warehouse is protected from unauthorized access, modification, and deletion. This includes access controls, data encryption, and audit trails.

Scalability
Ensure that the data warehouse can scale to accommodate growing data volumes and increased demand for analysis and reporting. This includes the use of distributed systems, data partitioning, and load balancing.

Maintenance
Develop a maintenance plan for the data warehouse, including regular backups, data archiving, and disaster recovery planning. This helps to ensure that the data warehouse is available and reliable for analysis and reporting.

The post Building a Data Warehouse appeared first on SQL Help.

Why the SQL TOP Statement Does Not Work in Oracle and What to Use Instead
Structured Query Language (SQL) is a fundamental tool for managing and querying relational databases. However, different database management systems (DBMS) have unique implementations and syntax variations. One such difference is the use of the TOP clause, which is prevalent in SQL Server but absent in Oracle Database. This article will explain why the TOP statement is not supported in Oracle and what alternatives can be used to achieve similar functionality.

The SQL TOP Statement: An Overview
In SQL Server, the TOP clause is used to limit the number of rows returned by a query. This is particularly useful for handling large datasets when only a subset of data is needed. The basic syntax for the TOP clause in SQL Server is:

SELECT TOP n * FROM table_name;

This command retrieves the first n rows from the specified table. The TOP clause is straightforward and convenient in SQL Server. However, this specific syntax is not recognized by Oracle Database.

Why Oracle Does Not Support the SQL TOP Statement
Oracle Database follows a different set of SQL standards and conventions. There are several reasons for the absence of the TOP clause in Oracle:

Adherence to SQL Standards: Oracle adheres closely to ANSI and ISO SQL standards, which do not include the TOP clause. The TOP clause is a proprietary feature introduced by Microsoft in SQL Server, and Oracle has chosen not to adopt this non-standard extension.

Alternative Mechanisms: Oracle offers other methods to achieve similar results as the TOP clause. These methods include the use of the ROWNUM pseudo-column, the FETCH FIRST clause (introduced in Oracle 12c), and the ROW_NUMBER() analytic function, each providing more standardized and flexible ways to limit query results.

Alternatives to the TOP Clause in Oracle
Using ROWNUM

The ROWNUM pseudo-column is an effective way to limit the number of rows returned by a query in Oracle. It assigns a unique number to each row in the result set, starting with 1. The syntax for using ROWNUM is:

SELECT * FROM table_name WHERE ROWNUM <= n
This query retrieves the first n rows from the table. However, it is important to note that ROWNUM is assigned before the ORDER BY clause is applied, which can affect the result if sorting is needed.

Using FETCH FIRST (Oracle 12c and Later)

Oracle 12c introduced the FETCH FIRST clause, which provides a more intuitive and standard-compliant way to limit rows. The syntax is:

SELECT * FROM table_name ORDER BY column_name FETCH FIRST n ROWS ONLY
This query returns the first n rows based on the specified order. The FETCH FIRST clause is straightforward and aligns with SQL standards, making it a preferred method for limiting rows in newer Oracle versions.

Using ROW_NUMBER() Analytic Function

The ROW_NUMBER() analytic function is another powerful tool for limiting rows in Oracle. It assigns a unique number to each row within a result set, allowing for precise control over row selection. The syntax is:

SELECT * FROM (
SELECT column_name, ROW_NUMBER() OVER (ORDER BY column_name) AS rn
FROM table_name
) WHERE rn <= n;

This query retrieves the first n rows after ordering the results by the specified column. The ROW_NUMBER() function offers great flexibility, especially for complex queries involving multiple columns and partitions.

Conclusion – Why the TOP statement is not supported in Oracle
The absence of the TOP clause in Oracle is due to its commitment to SQL standards and its design philosophy. However, Oracle provides robust alternatives to achieve similar functionality. The ROWNUM pseudo-column, the FETCH FIRST clause, and the ROW_NUMBER() analytic function each offer unique advantages, allowing users to efficiently limit the number of rows returned by their queries. By understanding and utilizing these alternatives, Oracle users can effectively manage large datasets and tailor their queries to meet specific needs.

The post Why the SQL TOP Statement Does Not Work in Oracle and What to Use Instead appeared first on SQL Help.