Trying to upgrade some databases from 8.3 to 9.1. In the database dumps are a lot of postgis functions like this that reference postgis files
CREATE FUNCTION st_box2d_in(cstring) RETURNS box2d
AS '/usr/lib/postgresql/8.3/lib/liblwgeom', 'BOX2DFLOAT4_in'
LANGUAGE c IMMUTABLE STRICT;
Is there a utility to uninstall all postgis 1.3.3 column types, functions etc from a database?
Related
I am using Visual Studio and a SQL Server Database Project to maintain my database objects through TFS. I have implemented a CLR Assembly for using RegEx Pattern matching in my UnitTests. I want to deploy this CLR to a different database than where the rest of the objects in the database would be deployed to.
Database_1 - contains all of the database objects
Database_2 - contains the CLR Assembly and UDFs for RegEx Pattern Matching.
I would like to create the script to deploy a CLR Assembly and related UDFs to one database, while creating the script which will deploy the rest of the changes to another database. I would like to do this using PRE/POST scripts using sqlcmd as I think this is the easiest way to do this.
Is this possible?
Publishing to another Database requires a different Database Project. They should be able to be in the same solution, but having two different Database projects will allow for different publishing properties (e.g. Target Database, etc).
OR, a very quick and easy to not worry about any of that would be to use the SQL# SQLCLR library of functions (which I wrote). The free version of SQL# contains several RegEx functions as well as many others. You can just save the installation script (once the correct Database name has been edited into the USE statement) into TFS and be done with it :-).
The PostGIS installation documentation reads:
PostGIS is an optional extension that must be enabled in each database you want to use it in before you can use it. Installing the software is just the first step. DO NOT INSTALL it in the database called postgres.
We're running PostgreSQL in Docker and only need one database, so we've been using the default database, postgres. My first inclination was to install PostGIS there, but the documentation seems pretty clear that we shouldn't be doing that.
Is there a reason for PostGIS not to be installed on the default database, or is this note meant to deter people from accidentally installing PostGIS in the postgres database when their data is in the foobar database?
Thanks!
There is no danger in installing PostGIS into the postgres database. The note is just so users don't confuse themselves, as you suspected.
I have strange problem.
I tried to move database from one server to another using pgAdmin III.
Database was created on server with PostgreSQL 8.4.9 and I wanted to move it on second server with PostgreSQL 8.2.11.
To do It, I used "backup" option and saved file, after that I used "restore" option on new database. Tables are loaded but there aren't any functions in new database.
Maybe it is because of different postgreSQL versions?
Does anyone know the reason? Any solution?
If the functions aren't around, double-check that plpgsql is available as a language. It's available by default nowadays, but making it available used to require a create language statement.
That said, I'd echo the comments: you really should be upgrading to a 9.x Postgres version that is still supported, rather than downgrading from an unsupported version to one that is even older.
I'd recommend to do it via pg_dump from an interactive session and export the complete database to one ore more sql files. There you can use the -s switch to have only the schema which should include created functions. Having this SQL file, you can also easier backport your changes or debug if something not applying to the old fallow.
We are multiple devs working on a project with MariaDb backend.
We would like to have revisions for our db schema changes & put this in source control.
Is there a way/tool to compare MariaDb database schemas & script these changes?
I know DbForge offers support for MariaDb, but Im looking for a free alternative to this tool.
Thanks
Make it simple. Dump schema with mysqldump tool(if I remember currectly, MariaDB has similar utils names) and save it in git/hg/svn.
mysqldump -u root -p --no-data dbname > schema.sql
It will create SQL query to create table, which will contain same format and every field will be on new line, so you can easily compare and make diffs in any tool to control versions.
There could be only one problem: commas. For example, if you have added new field, it will be added last, but previous will be changed - it will contain comma in the end at schema.sql, but it is common problem with any version-control tool, anyway you can find out more info by using diffs.
to compare the schema of two MariaDB databases I'd suggest to use:
TiCodeX SQL Schema Compare (https://www.ticodex.com).
It also gives you the migration script to update the destination database in case there are differences.
It's a nice tools that runs in Windows, Linux and Mac and can compare the schema of MS-SQL, MySQL, MariaDB and PostgreSQL database. Easy to use and effective. It may help you.
It's worth to mention that is the only tool I've found that also works nicely on Linux and MacOS.
We have a EF model of a DB2 database.
Is it possible to use this model to generate a SQL Server database? And then switch between using
DB2 and SQL Server?
We were thinking that the developers could develop against a local SQL Server database.
We use EF 4.1.
There can be problems with the field types, if you define them for yourself.
I have been doing such a thing with Sql-Oracle, and in the end, we where creating custom Attributes, like [VarcharAttribute] and configured the entities to use the correct typename in the OnModelBuilder function.
This might not work :
[Column(TypeName="varchar")]
public string Data{get;set;}
because for Oracle it should look like this :
[Column(TypeName="VARCHAR2")]
public string Data{get;set;}
Also there can be other problems, for example in the sql-oracle merge a table name was over 30 characters, and it worked in sql, but didn't work in oracle, because the table name was limited to 30 characters.
But after you fix these problems, then it will work. At the end we were able to set the provider from config file.
So yes, it is possible, if you take care of the database differences
Old question but...
You can't use migrations with IBM DB2 EF Provider.
About EF 6 (without migration) for DB2, now is supported by IBM
You can find official nuget package for EF support here
http://www.nuget.org/packages/EntityFramework.IBM.DB2/
but it does not support migrations.
If you need migration you can use also this package (in addition to previous package)
https://www.nuget.org/packages/System.Data.DB2.EntityFramework.Migrations/
You can find more info here
https://db2ef6migrations.codeplex.com/