Sorry if the question isn't phrased very well but I'm new to SSAS and don't know the correct terms.
I have changed the name of a table and its columns. I am using said table as a dimension for my cube, so now the cube won't process. Presumably I need to make updates in the analysis server to reflect changes to the source database?
I have no idea where to start - any help gratefully received.
Thanks
Phil
Before going into the details of how to amend the cube, have you considered creating a view with the same name as the old table which maps the new column names to the old?
The cube processing process should pick this up transparently.
EDIT
There are quite a lot of variations on how to amend SSAS - it depends on your local set-up.
If your cube definition is held in source control (which it should ideally be), you need to check the cube definition out and amend it from there.
If your definition exists only on the server you need to open it from the server:
Open the Business Intelligence
Development Studio (BIDS) -
typically on the Windows start menu
under Programs > Microsoft SQL
Server 2005.
Go to File > Open > Analysis Services Database
Select your server/database and click OK.
Once you have the project open in BIDS, you can amend the Data Source View to switch to the new table.
These instructions are based on the principle that it's going to be easier to alias the new table to look like the old in the DSV, since this means fewer changes within the cube definition.
Open the Data Source View from the Solution Explorer - there should be only one.
Locate the table you need to change in the DSV
Right-click on the table and select Replace Table > With New Named Query
Replace the existing query with a query from the new table with the new columns aliased with the new names:
SELECT ~new column name~ AS ~old column name~
FROM ~new_table~
Once the new query has been set, deploy the changes:
If you use source control, check in and deploy the project to the target server.
If you opened the cube definition from the server, select File > Save All
Finally, re-process the cube.
Related
I am in need of suggestion to move data from a particular table in one azure sql database to the other azure sql database which has the same table structure without using elastic query
Using SQL Server Management Studio to connect to SQL azure database, right click the source database and select generate scripts.
During the wizard, after have select the tables that you want to output to a query window, then click advanced. About half way down the properties window there is an option for "type of data to script". Select that and change it to "data only", then finish the wizard.
The heck the script, rearrange the inserts for constraints, and change the using at the top to run it against my target DB.
Then right click on the target database and select new query, copy the script into it, and run it.
This will migrate the data.
Please consider using the "Transfer SQL Server Objects task" in SSIS. You can learn all the advantages it provides on this article.
You can use PowerShell to query each database and move data between them as needed. Here's an example article on how to get this done.
Using PowerShell when working with Azure has a number of other benefits in what you can do and can control as well. It's a good choice to spend time learning.
In the source database I created SPs to select the data from the tables.
In the target database I created table types (which would be available in programmability) for the tables with the same structure as in the source.
I used Azure function to move the data into table type from source.
In the target database I created SPs to insert data into the tables from their respective table types.
After ensuring the transfer of data, I would be deleting those records moved to the target in the source database and for this I created SPs.
Is it possible to create cubes from XMLA just by replacing the the database and table names?
What I mean is that when you generate from one cube the script to create it, just replace all the related references to tables and database and change the datasource connection string. Now all the tables exist in the other database, I should be able to create a similar cube like this, right?
Basically you can do that but you should be careful not to break it. The XMLA for creating a cube is a whole description of the cube including calculated members, datasource, tables etc. If you want to change just the datasource connection string it is easy. Just one row in the XMLA file and it will work properly.
To change table names etc is very error prone - no matter if you do it by hand or using some regex. If you don't want to redesign the cube and the datasource in visual studio you can try with modifying the XMLA just be careful. Also keep in mind that in that XMLA (generated for example with Script database as create statement) you might also have users/roles/active directory IDs and stuff like that and if you move to another environment some of these might need to change also.
In the end when you try to process you will see if everything worked fine ;)
I've never touched PervasiveSql before and now I have a bunch of .ddf and .Btr files. I read that all I had to do was create a new database in the control center and point to the folder that contains these files.
When I do this and look at the database there is nothing in it. Since I am new to Pervasive, I'm more than likely sure that I'm doing something wrong.
EDIT: Added a screen shot after running command prompt
To create a database name in the PCC, you need to connect to the engine then right click the engine name and select New then Database. Once you do that, the following dialog should be displayed:
Enter the database name, and path. The path being where the DDFs are located. In most cases the default options are sufficient.
A longer process is documented at http://docs.pervasive.com/products/database/psqlv11/wwhelp/wwhimpl/js/html/wwhelp.htm#href=uguide/using.02.5.html.
If you pointed to a directory that had DDF files (FILE.DDF, FIELD.DDF,and INDEX.DDF) when you created the database name, you should see tables listed.
If you pointed to a directory that does not have DDF files, the database will still be created but will have no tables defined. You'll either need to get DDFs from the vendor or create the table entries using CREATE TABLE (with IN DICTIONARY clauses) or use DDF BUilder to add table entries.
Based on your screen shot, you only have 10 records in FILE.DDF. This is not enough. There are minimum system tables required (X$FILE, X$FIELD, X$INDEX, and a few others). It appears your DDFs are not a valid set. Contact the client / vendor that provided the DDFs and ask for a set that include all of the table definitions.
Once you have tables listed in your Database Name, you can use ODBC to access the data.
I have got a backup of a live database (A copy of an ACCDB format Access database) in which I've worked, added new fields to existing tables and whole new tables.
How do I get these changes and apply that fast in the running database?
In MS SQL Server, I'd right-click > Script Table As > Alter To, save the query and run it wherever I desire, is there an as easy way as that to do it in an Access Database ?
Details:
It's an ACCDB MS-Access database created on Access 2007, copied and edited in Access 2007, in which I need to get some "alter" scripts to run on the other database so that it has all the new columns and tables I've created on my copy.
For new tables, just import them from one database into the other. In the "External Data" section of the ribbon, choose the Access icon above "Import". That choice starts an import wizard to allow you to select which objects you want imported. You will have a choice to import just the table structure, or both structure and data.
Remou is right that you can use DDL ALTER TABLE statements to add new columns. However, DDL might not support every feature you want for your new columns. And if you want not just the empty columns added, but also also any data from those new columns, you will probably need to run UPDATE statements to get it into your new columns.
As far as "Script Table As", see if OmBelt's Export Table to SQL tool for MS Access can do what you want.
Edit: Allen Browne has sample ALTER TABLE statements. See CreateFieldDDL and the following one, CreateFieldDDL2.
You can run DDL in Access. I think it would be easiest to run the SQL with VBA, in this case.
There is a product called DbWeigher that can compare Access database schemas and synchronize them. You can get a free trial (30 days). DbWeigher will write a script of all schema differences and write it out as DDL. The script is thorough and includes relationships, indexes, validation rules, allow zero length, etc.
A free tool from the same developer, DBWConsole, will let you execute a DDL script against any Access database. If you wrote your own DDL scripts this would be an easy way to apply the changes to your live database. It even handles some DDL that I don't know how to process in VBA (so it must be magic). DBWConsole is included if you downloaded the trial version of DBWeigher. Be aware that you can't make schema changes to a table in a shared Access database if anyone has the table open.
DbWeigher creates a script of all differences between the two files. It can be a lot to manually parse through if you just want a few of the changes. I built a parser for DbWeigher script files so they could be filtered by table, to extract just the parts I wanted. I contacted the DbWeigher author about it but never heard back. It's safe to say that I have no affiliation with this developer.
I need to move selected data from 800+ tables in one database to the same 800+ tables in another database in another server. The data I select is based on date fields of every table. So, if I say table 1 date from 01/01/10 to 01/15/10, then only that data I want to be copied into the other server's database table specified.
I hope I am not confusing anyone. What is easiest way to do this?
Look into SSIS. What you're talking about is very easy using it. Here is a page that talks about using variables in SSIS.
If this is a one time solution and the destination database is going to be a brand new one. I would restore a backup from the source database and then delete all the records outside of the date range I want in the new database.
If this is a one time solution and you need to move the data to an existing database you can use the export/import wizard in SQL Server Management Studio (This is not in Express edition). Right click on the database go to task and select export data. Then you can use a query to select the data based on the date range from the source table.
You can also link the servers and just run an insert into Server1.database.dbo.table1 to Server2.database.dbo.Table2.
If you will be moving data everyday I would recommend you to create an SSIS package. You can use the Export Wizard and save the SSIS package at the end. Then you can modify the SSIS package using Visual Studio.