XMLA 엔드포인트를 사용하는 고급 증분 새로 고침 및 실시간 데이터
읽기-쓰기 작업에 대해 XMLA 엔드포인트를 사용하는 프리미엄 용량의 의미 체계 모델을 통해 고급 새로 고침, 파티션 관리, 도구를 활용한 메타데이터 전용 배포, 스크립팅 및 API 지원이 가능합니다. 추가로 XMLA 엔드포인트를 통한 새로 고침 작업은 하루 48회 새로 고침으로 제한되지 않으며 예약된 새로 고침 제한 시간이 적용되지 않습니다.
파티션
의미 체계 모델 테이블 파티션은 표시되지 않으며 브라우저에서 Power BI Desktop 또는 Power BI 서비스를 사용하여 관리할 수 없습니다. 프리미엄 용량에 할당된 작업 영역의 모델의 경우 테이블 형식 모델 스크립팅 언어(TMSL)로, 그리고 테이블 형식 개체 모델(TOM)로 프로그래밍 방식으로 스크립팅된 오픈 소스 테이블 형식 편집기인 SQL Server Management Studio(SSMS) 등과 같은 도구를 사용하여 XMLA 엔드포인트를 통해 관리할 수 있습니다.
처음으로 Power BI 서비스에 모델을 게시할 때 새 모델의 각 테이블에는 하나의 파티션이 있습니다. 증분 새로 고침 정책이 없는 테이블의 경우 이 하나의 파티션에 테이블의 모든 데이터 행이 포함됩니다(필터가 적용되지 않는 경우). 증분 새로 고침 정책이 있는 테이블의 경우 Power BI에서 정책을 아직 적용하지 않았기 때문에 초기 파티션 하나만 존재합니다. RangeStart 및 RangeEnd 매개 변수를 기반으로 테이블에 날짜/시간 범위 필터를 정의하고 다른 필터는 Power Query 편집기에서 적용한 경우 Power BI Desktop에 초기 파티션이 구성되었습니다. 이 초기 파티션에는 필터 조건을 충족하는 데이터 행만 포함됩니다.
첫 번째 새로 고침 작업을 수행할 때 증분 새로 고침 정책이 없는 테이블은 해당 테이블의 기본 단일 파티션에 포함된 모든 행을 새로 고칩니다. 증분 새로 고침 정책이 있는 테이블의 경우 새로 고침 및 기록 파티션이 자동으로 생성되고 각 행의 날짜/시간에 따라 행이 파티션에 로드됩니다. 증분 새로 고침 정책에 실시간 데이터 가져오기가 포함되는 경우 Power BI는 테이블에 DirectQuery 파티션도 추가합니다.
이 첫 번째 새로 고침 작업은 데이터 원본에서 로드해야 하는 데이터의 양에 따라 상당한 시간이 걸릴 수 있습니다. 새로 고침 작업에서 추가 처리 및 재계산을 수행해야 하기 때문에 모델의 복잡성도 중요한 요인이 될 수 있습니다. 이 작업은 부트스트랩될 수 있습니다. 자세한 내용은 초기 전체 새로 고침 시 시간 제한 방지를 참조하세요.
파티션은 기간 세분성(연도, 분기, 월 및 일)에 따라 생성되고 이름이 지정됩니다. 최근 파티션인 새로 고침 파티션에는 정책에서 지정한 새로 고침 기간의 행이 포함됩니다. 기록 파티션에는 새로 고침 기간까지의 전체 기간에 대한 행이 포함됩니다. 실시간 사용이 설정된 경우 DirectQuery 파티션은 새로 고침 기간의 종료 날짜 이후에 발생한 모든 데이터 변경 내용을 선택합니다. 새로 고침 및 기록 파티션 세분성은 정책을 정의할 때 선택한 새로 고침 및 기록(저장) 기간에 따라 다릅니다.
예를 들어 오늘 날짜가 2021년 2월 2일이고 데이터 원본의 FactInternetSales 테이블에 오늘까지의 행이 포함된 경우, 정책에서 실시간 변경 내용을 포함하도록 지정하고, 마지막 1일 새로 고침 기간에 행을 새로 고치고, 지난 3년 과거 기간의 행을 저장합니다. 그런 다음 첫 번째 새로 고침 작업을 사용하면 나중에 변경하기 위해 DirectQuery 파티션이 만들어지고, 오늘의 행에 대해 새 가져오기 파티션이 생성되고, 어제, 하루 전체, 2021년 2월 1일에 대한 기록 파티션이 만들어집니다. 이전 전체 월 기간(2021년 1월)에 대한 기록 파티션이 생성되고, 이전 연도 기간(2020년)에 대한 기록 파티션이 생성되고, 2019년과 2018년 전체 연도의 기록 파티션이 만들어집니다. 2021년 1분기가 아직 끝나지 않았기 때문에 전체 분기 파티션은 만들어지지 않습니다.
각 새로 고침 작업을 통해 새로 고침 기간 파티션만 새로 고쳐지고 현재 새로 고침 기간 이후에 발생하는 변경 내용만 포함하도록 DirectQuery 파티션의 날짜 필터가 업데이트됩니다. 업데이트된 새로 고침 기간 내 새 날짜/시간을 포함하여 새 행에 대한 새 새로 고침 파티션이 만들어지고, 새로 고침 기간의 기존 파티션 내에 날짜/시간이 이미 포함된 기존 행은 업데이트를 통해 새로 고쳐집니다. 날짜/시간이 새로 고침 기간보다 오래된 행은 더 이상 새로 고쳐지지 않습니다.
전체 기간이 종료되면 파티션이 병합됩니다. 예를 들어, 정책에 1일 새로 고침 기간과 3년 기록 저장 기간이 지정된 경우 해당 월의 첫째 날에 이전 달의 모든 날에 대한 파티션이 월 파티션으로 병합됩니다. 새 분기의 첫 번째 날에는 이전 3개월의 파티션이 모두 하나의 분기 파티션으로 병합됩니다. 새 연도의 첫 번째 날에는 이전 4개 분기의 파티션이 모두 하나의 연도 파티션으로 병합됩니다.
모델은 항상 전체 기록 저장 기간에 대한 파티션과 현재 새로 고침 기간을 통해 전체 기간에 대한 파티션을 유지합니다. 위의 예제에서 전체 3년 간의 기록 데이터는 2018, 2019, 2020년의 파티션에 유지되고, 2021Q101 월 기간, 2021Q10201 일 기간 및 오늘 날짜의 새로 고침 기간 파티션에도 유지됩니다. 3년에 대한 기록 데이터 유지를 선택했기 때문에 2018년 파티션은 2022년 1월 1일 첫 번째 새로 고침 때까지 유지됩니다.
Power BI 증분 새로 고침 및 실시간 데이터를 사용하면 서비스는 정책에 따라 파티션 관리를 처리합니다. 서비스에서 모든 파티션 관리를 처리할 수 있지만 XMLA 엔드포인트를 통해 도구를 사용하여 개별적으로, 순차적으로 또는 병렬 방식으로 일부 파티션만을 새로 고칠 수 있습니다.
SQL Server Management Studio를 사용한 새로 고침 관리
SSMS(SQL Server Management Studio)를 사용하여 증분 새로 고침 정책 애플리케이션에서 만든 파티션을 보고 관리할 수 있습니다. 예를 들어 SSMS를 사용하여 증분 새로 고침 기간에 없는 특정 기록 파티션을 새로 고쳐 모든 기록 데이터를 새로 고치지 않아도 소급 업데이트를 수행할 수 있습니다. 일괄 처리로 기록 파티션을 증분 방식으로 추가/새로 고침하여 부트스트랩을 통해 대용량 모델에 대한 기록 데이터를 로드하는 데 SSMS를 사용할 수도 있습니다.
증분 새로 고침 동작 재정의
SSMS에서는 TMSL(테이블 형식 모델 스크립팅 언어) 및 TOM(테이블 형식 개체 모델)을 사용하여 새로 고침을 호출하는 방법을 보다 세밀하게 제어할 수도 있습니다. 예를 들어, SSMS의 개체 탐색기에서 테이블을 마우스 오른쪽 단추로 선택하고, 프로세스 테이블 메뉴 옵션을 선택하고, 스크립트 단추를 클릭하여 TMSL 새로 고침 명령을 생성합니다.
이러한 매개 변수를 TMSL 새로 고침 명령에 사용하여 기본 증분 새로 고침 동작을 재정의할 수 있습니다.
applyRefreshPolicy. 테이블에서 증분 새로 고침 정책이 정의된 경우
applyRefreshPolicy가 정책 적용 여부를 결정합니다. 정책이 적용되지 않는 경우 전체 처리 작업을 수행하면 파티션 정의가 변경되지 않고 테이블의 모든 파티션이 완전히 새로 고쳐집니다. 기본값은 true입니다.effectiveDate. 증분 새로 고침 정책이 적용되는 경우 현재 날짜를 알고 있어야 증분 새로 고침 및 기록 기간의 이동 기간 범위를 결정할 수 있습니다.
effectiveDate매개 변수를 사용하여 현재 날짜를 재정의할 수 있습니다. 이 매개 변수는 과거 또는 미래의 날짜까지 데이터를 증분 방식으로 새로 고치는 테스트, 데모 및 비즈니스 시나리오에 유용합니다(예: 향후 예산). 기본값은 현재 날짜입니다.
{
"refresh": {
"type": "full",
"applyRefreshPolicy": true,
"effectiveDate": "12/31/2013",
"objects": [
{
"database": "IR_AdventureWorks",
"table": "FactInternetSales"
}
]
}
}
TMSL을 사용하여 기본 증분 새로 고침 동작을 재정의하는 방법에 대한 자세한 내용은 Refresh 명령을 참조하세요.
최적의 성능 보장
새로 고침 작업마다 Power BI 서비스는 각 증분 새로 고침 파티션에 대한 초기화 쿼리를 데이터 원본에 보낼 수 있습니다. 다음을 통해 초기화 쿼리 수를 줄여 증분 새로 고침 성능을 향상할 수 있습니다.
- 증분 새로 고침을 구성하는 테이블은 단일 데이터 원본에서 데이터를 가져와야 합니다. 테이블이 두 개 이상의 데이터 원본에서 데이터를 가져오는 경우 각 새로 고침 작업을 위해 서비스에서 보내는 쿼리 수가 데이터 원본 수의 배가 되므로 새로 고침 성능이 저하될 수 있습니다. 증분 새로 고침 테이블의 쿼리는 단일 데이터 원본을 대상으로 해야 합니다.
- 가져오기 파티션의 증분 새로 고침과 직접 쿼리를 사용하여 실시간 데이터를 모두 새로 고치는 솔루션의 경우 모든 파티션은 단일 데이터 원본의 데이터를 쿼리해야 합니다.
- 보안 요구 사항에서 허용하는 경우 데이터 원본 프라이버시 수준 설정을 조직 또는 퍼블릭으로 설정합니다. 기본적으로 프라이버시 수준은 프라이빗이지만 해당 수준에서는 다른 클라우드 원본과 데이터를 교환할 수 없습니다. 프라이버시 수준을 설정하려면 추가 옵션 메뉴를 선택한 다음 설정>데이터 원본 자격 증명>자격 증명 편집>이 데이터 원본에 대한 프라이버시 수준 설정을 선택합니다. 서비스에 게시하기 전에 Power BI Desktop 모델에서 설정하는 프라이버시 수준은 게시할 때 서비스로 전송되지 않습니다. 여전히 서비스의 의미 체계 모델 설정에서 설정해야 합니다. 자세한 내용은 개인 정보 수준을 참조하세요.
- 온-프레미스 데이터 게이트웨이를 사용하는 경우 버전 3000.77.3 이상을 사용해야 합니다.
초기 전체 새로 고침에 대한 시간 초과 방지
Power BI 서비스에 게시한 후에는 모델에 대한 초기 전체 새로 고침 작업에서 증분 새로 고침 정책에 정의된 전체 기간에 대한 증분 새로 고침 테이블에 대한 파티션을 만들고 기록 데이터를 로드하고 처리합니다. 많은 양의 데이터를 로드하고 처리하는 일부 모델의 경우 초기 새로 고침 작업을 수행하는 데 걸리는 시간은 서비스에 의해 적용되는 새로 고침 시간 제한을 초과하거나 데이터 원본에 의해 적용되는 쿼리 시간 제한을 초과할 수 있습니다.
초기 새로 고침 작업을 부트스트랩하면 서비스에서 증분 새로 고침 테이블에 대한 개체를 만들 수 있지만 기록 데이터를 파티션에 로드하고 처리할 수 없습니다. 그런 다음, SSMS를 사용하여 선택적으로 파티션을 처리합니다. 각 파티션에 대해 로드되는 데이터의 양에 따라 각 파티션을 순차적으로 또는 소규모 일괄 처리를 통해 처리하여 하나 이상의 파티션에서 시간 초과를 유발할 가능성을 줄일 수 있습니다. 다음 방법은 모든 데이터 원본에 작동합니다.
새로 고침 정책 적용
오픈 소스 테이블 형식 편집기 2 도구는 초기 새로 고침 작업을 부트스트랩하는 쉬운 방법을 제공합니다. Power BI Desktop에서 정의된 증분 새로 고침 정책이 있는 모델을 서비스에 게시한 후 읽기/쓰기 모드에서 XMLA 엔드포인트를 사용하여 모델에 연결합니다. 증분 새로 고침 테이블에서 새로 고침 정책 적용을 실행합니다. 해당 정책만 적용될 경우 파티션은 생성되지만 데이터는 로드되지 않습니다. 그런 다음, SSMS에 연결하여 파티션을 순차적으로 또는 일괄로 새로 고쳐 데이터를 로드하고 처리합니다. 자세한 내용은 테이블 형식 편집기 설명서의 증분 새로 고침 을 참조하세요.
빈 파티션에 대한 파워 쿼리 필터
모델을 서비스에 게시하기 전에 Power Query 편집기에서 ProductKey 열에 0 이외의 값을 필터링하는 다른 필터를 추가하여 FactInternetSales 테이블의 모든 데이터를 효과적으로 필터링합니다.
Power Query 편집기에서 닫기 및 적용을 클릭하여 증분 새로 고침 정책을 정의하고 모델을 저장한 후 서비스에 게시합니다. 그런 다음, 서비스에서 모델에 대한 초기 새로 고침 작업이 실행됩니다. FactInternetSales 테이블에 대한 파티션이 정책에 따라 생성되지만 모든 데이터가 필터링되므로 데이터가 로드되거나 처리되지는 않습니다.
초기 새로 고침 작업이 완료되면 Power Query 편집기로 다시 돌아가 ProductKey 열에 대한 추가 필터가 제거됩니다. Power Query 편집기에서 닫기 및 적용을 선택하고 모델을 저장하면 모델이 다시 게시되지 않습니다. 모델이 다시 게시된 경우 증분 새로 고침 정책 설정을 덮어쓰고, 서비스에서 후속 새로 고침 작업을 수행할 때 모델에 대해 전체 새로 고침을 실시합니다. 대신 모델에서 ProductKey 열에 대한 필터를 제거하는 애플리케이션 수명 주기 관리(ALM) 도구 키트를 사용하여 메타데이터 전용 배포를 수행합니다. 그런 다음, SSMS를 사용하여 파티션을 선택적으로 처리할 수 있습니다. SSMS에서 모든 파티션이 완전히 처리된 경우(모든 파티션에서의 프로세스 재계산이 포함되어야 함) 서비스에서 모델에 대한 후속 새로 고침 작업을 수행하면 증분 새로 고침 파티션만 새로 고쳐집니다.
SSMS에서 테이블 및 파티션을 처리하는 방법에 대한 자세한 내용은 데이터베이스, 테이블 또는 파티션 처리(Analysis Services)를 참조하세요. TMSL을 사용하여 모델, 테이블 및 파티션을 처리하는 방법에 대한 자세한 내용은 새로 고침 명령(TMSL)을 참조하세요.
데이터 변경 내용을 검색하기 위한 사용자 지정 쿼리
TMSL 및 TOM을 사용하여 검색된 데이터 변경 동작을 재정의할 수 있습니다. 메모리 내 캐시에서 마지막 업데이트 열을 유지하는 것을 방지하는 데 이 방법을 사용할 수 있을 뿐만 아니라, 새로 고쳐야 하는 파티션에만 플래그를 지정하기 위해 추출, 변환 및 로드(ETL) 프로세스가 구성 또는 명령 테이블을 준비하는 시나리오를 사용할 수 있습니다. 이 방법을 통해 데이터 업데이트 소요 시간에 관계없이 필요한 기간을 새로 고칠 수 있는 보다 효율적인 증분 새로 고침 프로세스를 만들 수 있습니다.
pollingExpression은 경량 M 식 또는 다른 M 쿼리의 이름으로 사용됩니다. 스칼라 값을 반환해야 하며 각 파티션에 대해 실행됩니다. 반환된 값이 마지막으로 증분 새로 고침이 수행된 때의 값과 다른 경우 해당 파티션은 전체 처리를 위해 플래그가 지정됩니다.
다음 예제에서는 소급 변경을 위해 120개월의 기록 기간을 모두 포함합니다. 10년 대신 120월을 지정하면 데이터 압축이 덜 효율적일 수 있지만 전체 기록 연도를 새로 고칠 필요가 없습니다. 월이 소급 변경에 충분한 경우에 이렇게 하면 비용이 더 듭니다.
"refreshPolicy": {
"policyType": "basic",
"rollingWindowGranularity": "month",
"rollingWindowPeriods": 120,
"incrementalGranularity": "month",
"incrementalPeriods": 120,
"pollingExpression": "<M expression or name of custom polling query>",
"sourceExpression": [
"let ..."
]
}
메타데이터 전용 배포
Power BI Desktop에서 작업 영역에 새 버전의 .pbix 파일을 게시할 때 동일한 이름의 모델이 이미 있는 경우 기존 모델을 바꿀지 묻는 메시지가 표시됩니다.
경우에 따라, 특히 증분 새로 고침을 사용할 때 모델을 바꾸지 않으려고 할 수 있습니다. Power BI Desktop의 모델은 Power BI 서비스의 데이터 세트보다 훨씬 작을 수 있습니다. Power BI 서비스의 모델에 증분 새로 고침 정책이 적용되는 경우 모델을 바꾸면 몇 년간의 기록 데이터가 손실될 수 있습니다. 모든 기록 데이터를 새로 고치면 시간이 걸리고 사용자에게 시스템 가동 중지 시간이 발생할 수 있습니다.
대신 메타데이터 전용 배포를 수행하는 것이 좋습니다. 이 경우 기록 데이터를 손실하지 않고 새 개체를 배포할 수 있습니다. 예를 들어 몇 가지 측정값을 추가한 경우 데이터를 새로 고치지 않고도 새 측정값을 배포할 수 있어 많은 시간이 절약됩니다.
XMLA 엔드포인트 읽기/쓰기를 위해 구성된 Premium 용량에 할당된 작업 영역의 경우 호환되는 도구를 사용하여 메타데이터 전용 배포가 가능합니다. 예를 들어 ALM 도구 키트는 Power BI 모델용 스키마 비교 도구이며 메타데이터 배포를 수행하는 데만 사용할 수 있습니다.
Analysis Services Git 리포지토리에서 최신 버전의 ALM 도구 키트를 다운로드하여 설치합니다. ALM 도구 키트 사용에 대한 단계별 지침은 Microsoft 설명서에 포함되어 있지 않습니다. ALM 도구 키트 설명서 링크 및 지원 정보는 도움말 리본에서 제공됩니다. 메타데이터 전용 배포를 수행하려면 비교를 수행하고 실행 중인 Power BI Desktop 인스턴스를 원본으로, Power BI 서비스의 기존 모델을 대상으로 선택합니다. 표시되는 차이점을 고려하여 증분 새로 고침 파티션이 있는 테이블의 업데이트를 건너뛰거나 옵션 대화 상자를 사용하여 테이블 업데이트를 위해 파티션을 유지합니다. 선택 항목의 유효성을 검사하여 대상 모델의 무결성을 확인한 다음 업데이트합니다.
증분 새로 고침 정책 및 실시간 데이터를 프로그래밍 방식으로 추가
또한 TMSL 및 TOM을 사용하여 증분 새로 고침 정책을 XMLA 엔드포인트를 통해 기존 모델에 추가할 수 있습니다.
참고 항목
호환성 문제를 방지하려면 최신 버전의 Analysis Services 클라이언트 라이브러리를 사용해야 합니다. 예를 들어 하이브리드 정책을 사용하려면 버전이 19.27.1.8 이상이어야 합니다.
프로세스에는 다음 단계가 포함됩니다.
대상 모델에 필요한 최소 호환성 수준이 있는지 확인합니다. SSMS에서 [모델 이름]>속성>호환성 수준을 마우스 오른쪽 단추로 클릭합니다. 호환성 수준을 높이려면 createOrReplace TMSL 스크립트를 사용하거나 다음 TOM 샘플 코드에서 예제를 확인합니다.
a. Import policy - 1550 b. Hybrid policy - 1565RangeStart및RangeEnd매개 변수를 모델 식에 추가합니다. 필요한 경우 날짜/시간 값을 날짜 키로 변환하는 함수도 추가합니다.원하는 보관(이동 기간) 및 증분 새로 고침 기간과
RangeStart및RangeEnd매개 변수를 기반으로 대상 테이블을 필터링하는 원본 식을 사용하여RefreshPolicy개체를 정의합니다. 실시간 데이터 요구 사항에 따라 새로 고침 정책 모드를 가져오기 또는 하이브리드로 설정합니다. 하이브리드로 설정하면 Power BI에서 테이블에 DirectQuery 파티션을 추가하여 마지막 새로 고침 시간 이후에 발생한 데이터 원본에서 최신 변경 내용을 가져옵니다.요구 사항에 따라 Power BI에서 테이블을 분할하도록 테이블에 새로 고침 정책을 추가하고 전체 새로 고침을 수행합니다.
다음 코드 샘플에서는 TOM을 사용하여 이전 단계를 수행하는 방법을 보여 줍니다. 이 샘플을 있는 그대로 사용하려면 AdventureWorksDW 데이터베이스의 복사본이 있어야 하며 FactInternetSales 테이블을 모델로 가져와야 합니다. 코드 샘플에서는 RangeStart 및 RangeEnd 매개 변수와 DateKey 함수가 모델에 없다고 가정합니다. FactInternetSales 테이블을 가져오고 모델을 Power BI Premium의 작업 영역에 게시합니다. 그런 다음, 코드 샘플을 모델에 연결할 수 있도록 workspaceUrl을 업데이트합니다. 필요에 따라 추가 코드 줄을 업데이트합니다.
using System;
using TOM = Microsoft.AnalysisServices.Tabular;
namespace Hybrid_Tables
{
class Program
{
static string workspaceUrl = "<Enter your Workspace URL here>";
static string databaseName = "AdventureWorks";
static string tableName = "FactInternetSales";
static void Main(string[] args)
{
using (var server = new TOM.Server())
{
// Connect to the dataset.
server.Connect(workspaceUrl);
TOM.Database database = server.Databases.FindByName(databaseName);
if (database == null)
{
throw new ApplicationException("Database cannot be found!");
}
if(database.CompatibilityLevel < 1565)
{
database.CompatibilityLevel = 1565;
database.Update();
}
TOM.Model model = database.Model;
// Add RangeStart, RangeEnd, and DateKey function.
model.Expressions.Add(new TOM.NamedExpression {
Name = "RangeStart",
Kind = TOM.ExpressionKind.M,
Expression = "#datetime(2021, 12, 30, 0, 0, 0) meta [IsParameterQuery=true, Type=\"DateTime\", IsParameterQueryRequired=true]"
});
model.Expressions.Add(new TOM.NamedExpression
{
Name = "RangeEnd",
Kind = TOM.ExpressionKind.M,
Expression = "#datetime(2021, 12, 31, 0, 0, 0) meta [IsParameterQuery=true, Type=\"DateTime\", IsParameterQueryRequired=true]"
});
model.Expressions.Add(new TOM.NamedExpression
{
Name = "DateKey",
Kind = TOM.ExpressionKind.M,
Expression =
"let\n" +
" Source = (x as datetime) => Date.Year(x)*10000 + Date.Month(x)*100 + Date.Day(x)\n" +
"in\n" +
" Source"
});
// Apply a RefreshPolicy with Real-Time to the target table.
TOM.Table salesTable = model.Tables[tableName];
TOM.RefreshPolicy hybridPolicy = new TOM.BasicRefreshPolicy
{
Mode = TOM.RefreshPolicyMode.Hybrid,
IncrementalPeriodsOffset = -1,
RollingWindowPeriods = 1,
RollingWindowGranularity = TOM.RefreshGranularityType.Year,
IncrementalPeriods = 1,
IncrementalGranularity = TOM.RefreshGranularityType.Day,
SourceExpression =
"let\n" +
" Source = Sql.Database(\"demopm.database.windows.net\", \"AdventureWorksDW\"),\n" +
" dbo_FactInternetSales = Source{[Schema=\"dbo\",Item=\"FactInternetSales\"]}[Data],\n" +
" #\"Filtered Rows\" = Table.SelectRows(dbo_FactInternetSales, each [OrderDateKey] >= DateKey(RangeStart) and [OrderDateKey] < DateKey(RangeEnd))\n" +
"in\n" +
" #\"Filtered Rows\""
};
salesTable.RefreshPolicy = hybridPolicy;
model.RequestRefresh(TOM.RefreshType.Full);
model.SaveChanges();
}
Console.WriteLine("{0}{1}", Environment.NewLine, "Press [Enter] to exit...");
Console.ReadLine();
}
}
}