I installed MariaDB and phpMyAdmin on my Synology at work and created a database. I was able to create the first fields with LO Base, which means that the JDBC-connector is working. The user hast % as location and I can edit everything from my machine with IntelliJ IDEA.
But: when I try to create a view with LO Base I get: The field names from 'database. Tables' could not be retrieved
I can see the data/rows in LO Base but I am not able to edit it. Which is possible in IDEA (add rows, modify content, etc.). I use the same credentials.
I do have the newest JDBC-driver/connector from the mysql-website and the connection-test worked. Is there a known issue with the latest release of base? I was able to do this in LO 4.X.
I use Ubuntu 16.04 on my laptop the synology OS is up to date, so as the packages.
Thanks in advance!
Just in case someone has the same problem: my database had underscores in the name. Removing them solved the issue.
Related
We currently run Uwamp 2.2.1.
Versiojn 3.1.0 is available. What i9s best practice when upgrading. i.e. how do do it? We are new to Uwamp, bit we successfully run an internal website based on mysql.
Thank you
I think the best practice when you do such a change of version (2.2.1->3.1.0) is :
1- Save your website (to a zip for example)
2- Save your MySQL database (in phpMyAdmin of the old UwAmp with the export option...)
3- Install the new version of UwAmp 3.1.0
4- Import your saves (database and website) in the new version of UwAmp.
Tell me if you want more detail...
I have puppet 3.4.2 and Vagrant 1.6.5. We configured our puphpet setup over a year ago.
This is all working fine on my environment, but a fresh install downloads a new version of the base box which has an updated version of puppet and so our old configurations don't work.
We are using this box: https://atlas.hashicorp.com/puphpet/boxes/ubuntu1204-x64. I must have v1 but for new instances it will download v2.1
I have tried updating the puphpet config.yaml, but when I upload this to puphpet.com I get the message "The config file provided was empty! Please recreate your manifest manually below.".
So I see a few solutions but I have blockers on each of them:
Use the old base box. Is there an archive copy of V1 of this server somewhere on the internet? https://atlas.hashicorp.com/puphpet/boxes/ubuntu1204-x64
Use the new base box but downgrade Puppet. How do you downgrade Puppet and all it's dependancies?
Figure out some way of importing my config.yaml in to puphpet.com and start using the new versions. Is there anything I need to do to get puphpet.com to recognise an old file?
Reconfigure the whole file from scratch. Do you know anyone that can help me?
Thanks for advice.
It's still there, but no longer supported or publically listed.
All boxes come pre-installed with Puppet 3.4.3, which is BC with 3.4.2.
Sorry, changes in the past month or two have broken BC with old config.yaml files. You'll need to manually select your options again.
Just do this. Honestly, it's textboxes, dropdowns and radio boxes, and will take you less than 10 minutes.
I refer this to enable the debugger in the PostgreSQL server in order to debugging the plpgsql function by stepping through the code using pgadmin.
I have already set shared_preload_libraries = '$libdir/plugins/plugin_debugger.dll' in the postgresql.conf, run pldbgapi.sql , and restarted the server.
These steps should have been run successfully and plugin_debugger.dll should be loaded successfully as can be verified by using the command show shared_preload_libraries, and I can see the debugging option in the context menu with a right click on a function in pgAdmin.
When choosing "Debugging" --> Debug, a window pops up to allow me to enter the values for the input parameters. But after that, when I press OK, it does not respond at all.
Any ideas or did I miss something in the setup of the debugger on the server?
I am using PostgreSQL 8.3 and pgAdmin 1.14
You have to enable debugging in two places. On PGAdmin and on the database itself. That article you referenced does a wonderful job explaining it but there were some nuances.
PGAdmin
When updating your postgresql.conf file to load the debugging library, I was running PGAdmin on Windows so the file was here:
C:\Program Files\PostgreSQL\9.4\data\postgresql.conf
And the path to the plugin_debugger.dll was actually
$libdir/plugin_debugger.dll
not
$libdir/plugins/plugin_debugger.dll
as specified in the article. So your postgresql.conf would need a line like this
shared_preload_libraries = '$libdir/plugin_debugger.dll'
Search for the actual .dll if you're in doubt. If you're on Linux the file you'll be looking for is plugin_debugger.so. Don't forget that changing the postgresql.conf file will require a restart for the change to take effect.
PostgreSQL Database
Assuming you're running your PostgreSQL database on a Linux server this gist does an excellent job at explaining how to download the dependencies for enabling debugging. Make sure you're running as root when you install.
The part that's easy to miss is issuing the command against the actual database you want to debug. For newer versions on PostgreSQL all you'll need to do is this:
CREATE EXTENSION IF NOT EXISTS pldbgapi;
If that doesn't return an error, you should be good to go.
Some additional things of note:
As mentioned above, you can only debug when running as a super user account
From their docs you can only debug pl/pgsql functions. So if your function says something like LANGUAGE c PGAdmin won't even show a right-click Debug menu option when you select the function. Look for something that has LANGUAGE plpgsql and the Debug menu should show.
Ken,
Have you tried pgAdmin 1.8 to rule out issue with PgAdmin 1.14/ PostgreSQL 8.3 interaction. It's been a while since I've used 8.3 and for the article I wrote -- which you are referring to, I was testing with 1.14/ PostgreSQL 9.1 so it could very well be an issue with the interaction with older version. Unfortunately I don't have a 8.3 anymore to test with.
I vaguely remember having the issue you had once, but it was when I had another shared library in my postgresql.conf in addition to the pldebugger. Can't remember which one that was, but removing the other shared library fixed my issue.
Hope some of these suggestions help,
Regina
I had the same problem.
Make sure the only shared lib you´re loading in the postgres.conf is the debugger.
Nothing else. Not even the profiler.
If you get a SSL error when trying to debug a function, reconnect to the server.
Am looking to upgrade Mangeto from version 1.1.8 to version 1.5.
This is a quite a leap I am taking I know, but and I have tried the following already (as some one else had suggested on another site):
dump v1.1.8 database, restore it in a new database.
install magento 1.5 pointing on the restored v1.1.8 database
let the upgrader run
add the old theme files
test that it all works.
When doing that, the upgrader kept saying some tables already existed.
Can anyone help me out?
Thanks
It's fine now, basically make sure you're using the same server environment.
Error in file:
/usr/local/sites/client/magento_site/app/code/core/Mage/Customer/sql/customer_setup/mysql4-upgrade-1.4.0.0.7-1.4.0.0.8.php" - SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'customer_form_attribute' already exists
I tried upgrading this using this tutorial from turnkeye to go from 1.4.1 -> 1.4.2 and then to 1.6 but after all the mage upgrading was complete, when I hit the website to upgrade the database I get errors about database tables that already exist and it appears to be running a database upgrade script for a version of magento before 1.4.2. I know this error is extremely common and I have seen many blogs posts about it and read all that I have found -- I see no resolution besides starting a fresh install.
I've heard people say this can happen if a previous upgrade didn't complete successfully but I don't think that is the case here -- I think it was a fresh install at 1.4.1 (at least I don't believe I ever upgraded it). Anyone know why this is happening or how to fix it?
Note 1: I also tried the upgrade by overwriting the 1.4.1 files via SSH with successive version of magento -- always the same database errors though. If I remove the mysql-upgrade script that is failing, then another one fails in its place with a simliar 'table already exists' error.
Note 2: I also made sure I cleared /var/cache and /var/session and even tried reindexing. No success.
Looks like it is just complaining about a table already existing. Either install a fresh version of you database from before you tried to upgrade then clear cache and sessions and try again
Or
Just open the file referenced and temporarly comment out the part that is installing the table again. That should allow you to by pass the error.
Then you can download the magento Database Repair Tool to ensure that your tables are correct.