5 thoughts on “Taking the Tabular Journey

  1. I had a working tabular model deployed, “had” being the operative word. I deleted the database on my ssas tabular instance in the hopes of fixing an odd deployment error I received after I added some new tables to my model. I was under the impression that when I went Build > Deploy it would re-create my database and I would carry on developing. That is not the case. Now every deployment attempt results in a generic error on “Deploy metadata” stage :

    Either the user, UserName, does not have access to the DatabaseModelName database, or the database does not exist.

    In this case, the error is very accurate and it no longer exists. I’m the admin for the SQL Server 2012 instance I’m trying to deploy to. How do I force it to create a new database/get it deployed again? Renaming the project, changing the database name, etc in the properties does not help. Your help is greatly appreciated thanks!

    • That’s an interesting and seemingly simple question that deserves more than just a simple answer. Here’s why: The ADOMD data provider returns results from an MDX or DAX query as a set to its client. Internally, though, something very different is happening in the tabular engine. Contrast this with the SSAS Multidimensional query engine which typically works with data in sets. In fact, one way to tell whether OLAP/MDX queries are efficient is whether the query engine is able to process the data in “block” computation mode or in “cell-by-cell” computation mode. This kind of reinforces your question of “sets” vs “row-by-row” (in the case of an OLAP structure, actually; “cell-by-cell”). By contrast, the tabular query engine, internally, is always working row-by-row with less overhead to manage than more traditional storage and query technologies. Relational and multidimensional engines, way deep down inside the guts of the machine, are also working with rows and other objects one-at-a-time. They just return sets when they’re done. The magical thing about tabular is that these row-by-row operations are all processed in memory. Without any fancy, internal caching machine that swaps things between disk and memory, the tabular engine simply loads all the data up into memory and works with it in-place. There are no indexes — no clusters, heaps, partitions or file groups. There’s just one structure of compressed data that gets read and processed one-row-at-a-time without incurring any IO cost at query time. In the end, the server-side data provider does build a single result set that gets sent to the client.

  2. Pingback: SQL Server 2012: Multidimensional vs tabular | James Serra's Blog

Leave a Reply