Forum Discussion
updating .sqlproj file (version issue with git)
- 15 days ago
Hi justfetz ,
Yes, it is generally recommended to manage the Warehouse separately from the front-end items, particularly in a larger or production environment.
- Warehouse/Data workspace: Hosts the Fabric Warehouse and other core data-layer components such as staging/ETL objects, pipelines, and data transformations.
- Front-end workspace: Hosts the semantic models, reports, dashboards, and other presentation-layer items that consume data from the Warehouse.
- Separation of responsibilities: This keeps the data layer isolated from report development and reduces the risk of changes to reports or semantic models affecting the underlying Warehouse.
- Security and access: Different permissions can be applied to the data and front-end workspaces. Data engineers can have broader access to the Warehouse workspace, while report developers/business users can have access to the front-end workspace as required.
- Deployment and lifecycle management: Separating the workspaces can make CI/CD and deployment management easier because the Warehouse and front-end artifacts can follow their own development and release cycles.
- Dependency management: The semantic models can connect to the Warehouse in the dedicated data workspace, while reports consume the semantic model rather than directly interacting with the Warehouse wherever possible.
So, the recommended architecture is typically Data/Warehouse layer → Semantic Model → Reports/Dashboards, with the Warehouse and front-end artifacts managed in separate workspaces when there is a need for stronger isolation, security, and independent deployment.
Thanks,
Chaithanya.
Hi justfetz
We ran into the same issue when we needed to update the SQL solution file in order to get some queries to work the way we want to, we are using YAML pipelines to build and deploy the solution, our pipeline failed on the build validation of the SQL solution of our queries, that was why we were looking to update.
We had the same issue that the update was oke for a second, but reverted and showed a change back to the old version in the workspace
Our solution was to, set the build version during our build so we could validate the SQLproj file, i have included our solution from our build pipeline. Hopefully this helps you with your issue.
Did I answer your question, please mark the post as a solution.
- name: sqlProjSdkVersion
value: '2.2.0'
# Build-only override. Fabric's git integration regenerates the
# <Sdk Name="Microsoft.Build.Sql" Version="..."/> line in the .sqlproj
# on every Commit from the workspace, so it must never be edited in git
# (it will just show up as a revert diff in the Fabric portal). Pin the
# version the CI build actually needs here instead, and patch it only into
# this pipeline's disposable checkout, right before the dotnet build step.
# Patch the SDK version only in this ephemeral checkout, never committed back.
# Keeps the file Fabric owns untouched in git while giving the build the SDK
# version it needs. Regex matches whatever version Fabric last wrote, since that
# value can change over time as Microsoft updates the backend build packages.
# Every *.Warehouse folder under folder/ is discovered and built, so adding
# a new Warehouse to the solution needs no change to this pipeline.
- script: |
set -e
shopt -s nullglob
FOUND=0
for SQLPROJ in folder/*.Warehouse/*.sqlproj; do
FOUND=1
echo "Pinning SDK version in ${SQLPROJ}"
sed -i -E "s/(<Sdk Name=\"Microsoft.Build.Sql\" Version=\")[^\"]*(\")/\1$(sqlProjSdkVersion)\2/" "$SQLPROJ"
# Report the resulting line, but never fail the step on a non-match:
# under set -e a grep that finds nothing would abort the whole build.
grep -m1 'Microsoft.Build.Sql' "$SQLPROJ" || echo " (no Microsoft.Build.Sql SDK line in this project)"
done
if [ "$FOUND" -eq 0 ]; then
echo "##vso[task.logissue type=error]No .sqlproj found under folder/*.Warehouse/"
exit 1
fi
displayName: 'Pin Microsoft.Build.Sql SDK version (build-only, not committed)'Hi thank you very much for this. I was out sick yesterday and I plan to look at this today. This is more helpful than the Microsoft documentation. Both methods presented on their website don't seem to fix the issue. I will update soon.