innodb_strict_mode=OFF MariaDB 10.4 - database

I need to turn off inno_strict_mode
Following is my current my.cnf file
Is it correct to change in this way?

Related

postgreSQL dump file generated when exporting is blank

I have a database named housing that I want to export. However, everytime i export it, it generates a blank dump file. I cannot identify what I've been doing wrong. Please help.
I'm trying using phppgadmin, I clicked export, selected SQL, structure and data as format and then download, but the dump file generated is always blank.
I think I know now what the problem is, I have different two versions of postgreSQL installed on my laptop. postgreSQL version 9.3.6 that comes with Bitnami WAPPstack) and I forgot that I had previously installed postgreSQL version 9.4.1 too. I get a pg_dump aborting because of server version mismatch. How do I fix this? Can I just simply uninstall the one that is not with the Bitnami WAPPStack? Or will my database be deleted along with it? I'm sorry I know nothing . :(
http://www.expertphp.in/article/postgres-phppgadmin-problem-empty-sql-dump-after-export
https://www.youtube.com/watch?v=L4W_6jnBXk0
Short:
In /usr/share/phppgadmin/dbexport.php.
Change the line from :
$cmd = $exe . " -i";
To
`$cmd = $exe;
and then change
passthru($cmd);
To
echo passthru($cmd);

Postgres Migration Issue 9.0.0 to 9.3, collation error

I was trying to migrate from PostgreSQL data from PostgreSQL 9.0.0 to 9.3. I am having an issue related to the collation.
ERROR: could not determine which collation to use for string comparison
Hint: Use the COLLATE clause to set the collation explicitly.
I have done quite a research and found that it has an issue in pre-9.1 we have "citext" and in post-9.1 we have to add the extension. [if I understood correctly].
Here what I have done so far :
Taken the dump from 9.0.0 database.
Installed the instance 9.3.1 in another instance.
Created a database there and run the following query to add the extension CREATE EXTENSION citext. Till here I do not have problem.
While importing the dump from 9.0 after executing the query, I am getting a error, as extension "citext" already exists.
I am not sure if i have done the correct steps in resolving the problem. As per mu understanding, in post 9.1 postgres, we do not have "citext" extension so we manually adding the extension by running the query. So now why it is trying to add the "citext" extension "create citext;" to add citext.
Please correct me if i am leading in a wrong direction.
Thanks
Sovan

Restore PostgreSQL database from mounted volume

My EC2 database server failed, preventing SSH or other access (not sure why ... grrr AWS ... that's another story).
I was able to make a snapshot of the EBS root volume. I can not boot a new instance from this volume (I'm guessing the boot partition is corrupt). However, I can attach and mount the volume on a new instance.
Now I need to get the PostgreSQL 8.4 on the new machine (Ubuntu 10.04) to load the data from the mounted volume. Is this possible? I've tried:
pg_ctl start -D /<mount_dir>/etc/postgresql/8.4/main/
But no joy ... PostgreSQL just starts with empty tables.
Is /etc/postgresql/8.4/main/ the correct location for PostgreSQL data files?
Is there a way to recover the data from the mounted volume in a way that PostgreSQL can read again?
(You should really specify your distro and version, etc, with this sort of system admin question.)
Running Pg via pg_ctl as shown above should work, assuming the original database was from Pg 8.4 and so are the binaries you're trying to use to start it. Perhaps you forgot to stop the instance of PostgreSQL automatically started by the distro? Or connected on the wrong port, so you got the distro's default instance instead of your DB on another port (or different unix socket path, for unix sockets)?
Personally I wouldn't do what you're doing anyway. First, before I did anything else, I'd make a full backup of the entire data directory because you clearly don't have good backups, otherwise you wouldn't be worrying about this. Take them now, because if you break something while restoring you're going to hate yourself. As demonstrated by this fault, trusting Amazon's storage (snapshot or otherwise) probably isn't good enough.
Once you've done that: The easiest way to restore your DB will be to, on a new instance you know you don't have any important data on that has the same major version (eg "8.4" or "9.0") of postgresql as your original instance did installed:
/etc/init.d/postgresql-8.4 stop
datadir=/var/lib/postgresql/8.4/main
rm -rf "$datadir"
cp -aR /<mount_dir>/etc/postgresql/8.4/main/ "$datadir"
chown -R postgres:postgres "$datadir"
/etc/init.d/postgresql-8.4 start
In other words: take a copy, fix the permissions, start the DB.
You might need to edit /etc/postgresql/8.4/main/postgresql.conf and/or /etc/postgresql/8.4/main/pg_hba.conf because any edits you made to the originals aren't there anymore; they're on your corrupted root FS. The postgresql.conf and pg_hba.conf in the datadir are just symlinks to the ones in etc under Debian - something I understand the rationale behind, but don't love.
Once you get it running, do an immediate pg_dumpall and/or just a pg_dump of your important DB, then copy it somewhere safe.

Mount Intersystem cache database

I have intersystem cache database file (cache.dat around 160MB). From management portal, I created a new database which point to my file.
But when i go for mounting the file into database, it gives me an error -
ERROR #86: the database default collation is not available
Please help me on this.
For your information i am using intersystem cache version 2011.1.2
Make a COPY, convert copy with cvendian:
noddy#chopin 11:24:36 /scratch3/noddy/chopin/mgr/db16k
$ ../../bin/cvendian CACHE.DAT
This database is little-endian.
This database has a block size of 16384 Bytes.
This database has 1 volume and 1 map.
The last block in the primary volume is 768.
Original manager directory is /home/isc/cache/mgr/db16k/
No extension volumes.
Done converting CACHE.DAT to big-endian
Hope this appears in a timely fashion
That means that you either trying to mount Unicode database on 8 bit system (or vice versa) or you are trying to mount a database with collation that is not installed to your cache system. In the last case you will need to install a locale file with required collation. You can look into cconsole.log file in mgr directory to see if there is a better error description there.
I had this problem, and I believe it was because I was trying to mount a database that was big-endian on a little-endian system (or maybe the other way around--doesn't really matter.) I'm not certain this was the problem, but it's the only difference I can think of between the two databases I was trying to mount.

how to get Roundhouse to create db on second hard drive

I want Roundhouse to create the db on a second hd (not the C drive which it does right now). Is there any way in Roundhouse to do this ? Iam using sql server 2008 r2 express. I tried the -cds option for custom db creation but it gives an error saying does not provide facility at this time.
thank you
First you must know how you would create it in T-SQL outside of RoundhousE. If you verify that it works with SQL Express, then you can provide the script to rh as text or (with the newest in trunk and soon to be released 0.8.5) you can point it to a script file that it will read.
If you are using an older version of RH, you MUST give the actual text to /cds and not a path to a file. That text cannot contain the word GO in it at all either. Both of these things will be fixed when 0.8.5 is released.
HTH

Resources