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.
Related
Say my code looks like this:
create database name1 on (name = N'name2', filename = N'C:\SQL\name3')
name3 I understand.
Now, 'name2' is supposed to be the "logical name". From what I can find, this means that this is the appropriate name to refer to this database in database engine. However USE name2, returns an error. In contrast, USE name1 works just fine.
The best answer I could find was here, but it was closed before the answer could be clarified (what would be an example where I would use it rather than name1?).
My question: What is the purpose of name2? When would I ever need to use it over name 1? Why is it a required component for file_spec?
Thanks. (SQL Server 2008 R2)
A database can reside in multiple files, for example:
CREATE DATABASE DatabaseName
ON (NAME='LogicalName1', FILENAME='C:\SQL\PhysicalName1.mdf'),
(NAME='LogicalName2', FILENAME='C:\SQL\PhysicalName2.mdf')
GO
USE DatabaseName
SELECT * FROM sys.database_files
In the above example, you can see that in addition to the two data files specified, a transaction log file was also created. This file has a different role than the data files (it records every change in the database, so it can be rolled-back if the transaction is not completed).
If you use multiple data files (in the same filegroup), they are both filled proportionally and this is useful for performance, if they are stored on separate disks.
If you use multiple data files in separate filegroups, you can specify the location of each table (and index), so you are able to place a table that is accessed more frequently on a separate, high-performance (and high-cost) disk.
See https://technet.microsoft.com/en-us/library/ms187087.aspx for details.
As Gordon already said, the logical file name is used in the ALTER DATABASE statement, when you need to refer to a particular file. Using this command, you may change the size of the file, the auto-growth settings or put a particular file offline. Also, you can move the file to another physical location. See https://msdn.microsoft.com/en-us/library/bb522469.aspx
In a SQL database, I can run a query to present information as it exists, and I can create new compilations of data that did not previously exist.
For instance, SELECT * FROM Table1 would return information that already existed, while a series of nested joins and WHERE statements could present data in ways that didn't exist before the query was run.
My question is whether the database's information schema -- assuming it's never been pulled up before -- falls into the first category or the second.
Information schema views query already existent system tables in database. You can control yourself as sys.tables etc which are called catalog views in Sql server.
Therefore using these views falls to second type of usage in your question. Using existent data in a different way.
Everything in INFORMATION_SCHEMA is just a view on the system tables. So the answer to your question is both that the data has always been there (because every object in the database has one or more rows in system tables somewhere representing it) and also that it's generated for your viewing pleasure upon querying (to present it in the form that INFORMATION_SCHEMA requires).
Note that even what we normally call "the system tables" (sys.tables and related) are also just views on the real, actual, physical system tables, which are not accessible to any user but only to the database engine itself -- viewing those directly requires a direct administrator connection and tweaking some flags, and is typically not something done by anyone other than SQL Server developers.
As to what this implies in a FOIA context is probably best answered in a legal setting, not an information-theoretical one.
I am not sure how to ask this question so please direct me in the right direction if I am not using the appropriate terminology, etc. but I can explain what I am currently doing. I would like to know if there is an easier way to update content in the database than the method I'm currently using.
(I'm using SQL Server 2008 BTW.)
I have a bunch of CSV files that I use to give to my client as a means to update content which gets imported into the DB (because the content is LARGE). The import works by running a python script that I wrote that makes use of a Jinja2 template that generates the SQL file needed to insert the CSV content into the database (if it is a from-scratch scenario). This is working fine.
Now when it comes to data migration (I need to migrate the data that exists in the DB to a new version thereof) I have a lot of manual work (I hand code it in the template, there is no SQL command or auto-generated code that I can run to do this for me) to do.
So lets say I have a list of Hospitals in a CSV file and I already have a set of hospitals in the database (which is imported from the previous version of the CSV file). I create a copy of the Hospitals table (without the data) and call it HospitalsTemp. The new CSV hospitals are inserted into the HospitalsTemp table (at least that part is generated via the template).
The Hospitals table now gets detached from all its foreign-keys and constraints. Now I go through all the tables surrounding the Hospitals (again manually!) and replace the hospitalId which pointed to the old hospitalId with the new hospitalId (as I can do a lookup from the Hospitals to the HospitalsTemp based on the hospital code to ensure that referential integrity is retained).
Then I delete the Hospitals table and rename the HospitalsTemp to Hospitals and put back the foreign-keys and constraints on the new Hospitals table.
I hope I explained it well enough for everyone to understand. I'm really hoping for a simpler way to do this.
How do you know which hospital becomes which, do the names stay the same? Is there an Id that stays the same?
Have you looked at SSIS, and the Slowly Changing Dimension component? You can use it to update existing rows and add new rows: http://blogs.msdn.com/b/karang/archive/2010/09/29/slowly-changing-dimension-using-ssis.aspx
Also SSIS would be a good tool for the import, as it handles reading CSV files well.
You could replace the current logic with simple SSIS package that's just a flat-file data source and the output of the SCD wizard by the sounds of it?
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.
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.