I am on leopard. It comes with Ruby 1.8 & Sqlite3 pre-installed. I have updated ruby to 1.9.1 & added Mysql. Here's the problem. I cannot get the path to correctly point to ruby 1.9.1. I tried to update the sym-link to no avail. I am able to get into Mysql from the terminal but I cannot connect to the server through Ruby because Sqlite3 is the default. I changed the database in my apps config file but it still doesn't work. Something is really screwing this up. I want to unistall every version of Ruby, Rails, All Gems, Mysql, Sqlite3, etc & roll all of what I want on my own. Where can I find the commands through the command line to do this? Can I just send these files to the trash manually as I find them on /usr/local/....? I am really frustrated at this point! please help.
Re-installing those packages will still not guarantee that its going to work. I would recommend go through the logs and see if you pick up some something obvious. There are lots of debugging techniques available for a Rails app, for starters see here
Here's a small ruby snippet to see if the connection to MySQL works fine, give it a try if you see the MySQL server version being printed on your terminal then you know the problem is somewhere else, do not forget to change the credentials.
#!/usr/bin/ruby -w
require "mysql"
begin
# connect to the MySQL server
dbh = Mysql.real_connect("localhost", "testuser", "testpass", "test")
# get server version string and display it
puts "Server version: " + dbh.get_server_info
rescue Mysql::Error => e
puts "Error code: #{e.errno}"
puts "Error message: #{e.error}"
puts "Error SQLSTATE: #{e.sqlstate}" if e.respond_to?("sqlstate")
ensure
# disconnect from server
dbh.close if dbh
end
Also if possible please provide some more details about the environment you are using, like
Apache + Rails + Mongrel or
Apache + Rails + Passenger etc
a snippet of your app/config/database.yml etc
If you are frustrated, take a break , relax, have a coffee :-) and then start over again....working in a frustrated state of mind is definitely not going to help solve problems.
HTH
Related
I'm trying to set a MySQL Database in my pc for development.
Of course I've tried to change the OS
None of this options made it work.
Although when I hit the testconnection button it shows success, the OS message error keeps being shown and I cannot use my database.
Any help will be appreciated. Thanks in advance!
You have to go to the control panel, then region, then clic in the administrative tab and click on "change system regional settings" and as a final step check the box: Beta: Use Unicode UTF-8 for worldwide language support, restart your PC and try to access MySQL Workbench.
Although the option proposed by Fernando Valderrama Guayán is functional I would not recommend activating a beta version option, since depending on your configuration strange symbols could appear in the rest of the operating system.
The solution with less collateral effects would be to edit the file 'os_utils.py' in the path 'C:\Program Files\MySQL\MySQL Workbench 8.0\workbench'.
We look for the line:
process = subprocess.Popen(command, stdin = subprocess.PIPE, encoding='utf-8', stdout = subprocess.PIPE, stderr = subprocess.STDOUT, shell=True)
And we replace it with:
process = subprocess.Popen(command, stdin = subprocess.PIPE, encoding='ansi', stdout = subprocess.PIPE, stderr = subprocess.STDOUT, shell=True).
The idea is to modify the encoding parameter to the ansi encoding system.
It's a bug in MySQL Workbench 8.0.28
Using MySQL Installer, you can uninstall the workbench then install the MySQL Workbench 8.0.16.
It will work well.
I'm working on a Perl6 project, but having difficulty connecting to MySQL. Even when using the DBIish (or perl6.org tutorial) example code, the connection fails. Any suggestions or advice is appreciated! User credentials have been confirmed accurate too.
I'm running this on Windows 10 with MySQL Server 8.0 and standard Perl6 with Rakudo Star. I have tried modifying the connection string in numerous ways like :$password :password<> :password() etc. but can't get a connection established. Also should note that I have the ODBC, C, C++, and.Net connectors installed.
#!/usr/bin/perl6
use v6.c;
use lib 'lib';
use DBIish;
use Register::User;
# Windows support
%*ENV<DBIISH_MYSQL_LIB> = "C:/Program Files/MySQL/MySQL Server 8.0/liblibmysql.dll"
if $*DISTRO.is-win;
my $dbh = DBIish.connect('mysql', :host<localhost>, :port(3306), :database<dbNameHere>, :user<usernameHere>, :password<pwdIsHere>) or die "couldn't connect to database";
my $sth = $dbh.prepare(q:to/STATEMENT/);
SELECT *
FROM users
STATEMENT
$sth.execute();
my #rows = $sth.allrows();
for #rows { .print }
say #rows.elems;
$sth.finish;
$dbh.dispose;
This should be connecting to the DB. Then the app runs a query, followed by printing out each resulting row. What actually happens is the application hits the 'die' message every time.
This is more of a work around, but being unable to use use a DB is crippling. So even when trying to use the NativeLibs I couldn't get a connection via DBIish. Instead I have opted to using DB::MySQL which is proving to be quite helpful. With a few lines of code this module has your DB needs covered:
use DB::MySQL;
my $mysql = DB::MySQL.new(:database<databaseName>, :user<userName>, :password<passwordHere>);
my #users = $mysql.query('select * from users').arrays;
for #users { say "user #$_[0]: $_[1] $_[2]"; }
#Results would be:
#user #1: FirstName LastName
#user #2: FirstName LastName
#etc...
This will print out a line for each user formatted as shown above. It's not as familiar as DBIish, but this module gets the job done as needed. There's plenty more you can do with it to, so I highly recommend reading the docs.
According to this github DBIish issue 127
The environmental variable DBIISH_MYSQL_LIB was removed. I don't know if anyone brought it back.
However if you add the library's path, and the file is named mysql.dll, it will work. Not a good result for the scientific method.
So more testing is needed - and perhaps
C:\Program Files\MySQL\MySQL Server 8.0\lib>mklink mysql.dll .\libmysql.dll
Oviously you can create your own lib directory and add that to your path and then add this symlink to that directory.
Hope this helps. I've spent hours..
EDIT: Still spending time - accounting later.
Something very transitory is going on. I reset the machine (perhaps always do this from now on), and still got the missing mysql.dll errors. Tried going into the MySQL lib directory to execute raku from there.. worked. changed directories.. didn't work.
Launched administrator cmd - from home directory, tried the raku command. Worked. Ok - not good, but perhaps consistent. Launched non admin cmd, tried it from the MySQL lib directory, worked. And just for giggles, tried it outside of that directory.. worked.
Now I can't get it not to work. Will explore NativeLibs::Searcher as Valle Lukas suggested!
Maybe the example in the dbiish repository is not valid anymore.
The DBIISH_MYSQL_LIB Env seems to be replaced by NativeLibs::Searcher with commit 9bc4191
Looking at NativeLibs::Searcher may help to find the root cause of the problem.
I am trying to set up a brand new Ghost blog on a Centos 7 server. I have Nginx, Node and Ghost installed and have written all of the necessary configuration files. It's pretty close to working, but I wanted to use MySQL instead of SQLite, so I created a new (blank) MySQL database called "ghost_db", set up a MySQL user called "ghost", gave the user permission for the database, and added these lines to config.js:
database: {
client: 'mysql',
connection: {
host: 'localhost',
user: 'ghost',
password: 'mypassword',
database: 'ghost_db'
charset: 'utf8'
filename: path.join(__dirname, '/content/data/ghost-dev.db')
},
debug: false
}, ...
When I try to start it, I get an error that suggests I use knex-migrator to initialize the database.
[john#a ghost]$ npm start
> ghost#1.18.4 start /var/www/ghost
> node index
[2017-12-10 00:08:00] ERROR
NAME: DatabaseIsNotOkError
CODE: MIGRATION_TABLE_IS_MISSING
MESSAGE: Please run knex-migrator init ...
However, some comments on Stackexchange suggest that using knex-migrate may be unnecessary for this version of Ghost, and when I run knex-migrator, it also fails:
[john#a ghost]$ knex-migrator init
[2017-12-09 16:21:33] ERROR
NAME: RollbackError
CODE: SQLITE_ERROR
MESSAGE: delete from "migrations" where "name" = '2-create-fixtures.js' and "version" = 'init' and "currentVersion" = '1.18' - SQLITE_ERROR: no such table: migrations
...[omitted]
Error: SQLITE_ERROR: no such table: migrations
I think the problem may be that the "ghost_db" database I initially created is blank. The "ghost-dev.db" file that is pointed to in the config.js seems to be for SQLite, but I get the same error message if I switch config.js back to using an SQLite database. I don't know what the "migrations" table is. I found the schema that I think Ghost expects at [https://github.com/TryGhost/Ghost/blob/1.16.2/core/server/data/schema/schema.js], but I'm not sure how to use that to initialize the tables, etc., except for doing it very laboriously by hand. I'm stumped!
Knex-migrator is new in Ghost 1.0, which also uses a config.<env>.json file for configuration.
It sounds like you added your database config into a file called config.js which was correct <1.0, however it seems you were installing Ghost 1.0 and therefore your new connection details would have needed to live in config.production.json.
You are correct that Ghost-CLI isn't intended for use on CentOS (it's for Ubuntu), but I'd be very surprised if it failed to install Ghost correctly. The issues with other OSs are mainly in the subtle differences between systemd i.e. keeping Ghost running.
The answer for me was just to not create the database at all and let Ghost do it as part of ghost install.
I took an alternate approach which proved successful, which was to install Ghost as an NPM module. The official Ghost instructions label this as an "advanced" process, but it wasn't too difficult to follow the instructions in the excellent nehalist.io and Stickleback blogs. There was also some useful guidance on the HugeServer knowledgebase. I think ultimately the problem was that the Ghost commandline interface (ghost-cli) wasn't designed for Centos 7.
http://localhost:3000/genre
I'm using Instant Rails, I'm introducing scaffolding for the first time ever.
So everything looks like its working fine, I did my own RoR page etc, today i come in today and when I go to localhost:3000 I get the following error message:
Oops! Google Chrome could not connect to localhost:3000
Any suggestions of what I should check would be greatly appreciated. So far I know to confirm that:
the windows host file connects 127.0.0.1 to localhost
I've had an update to this the Mongrel server doesnt start properly with the new app I have created, rather than an open window, it just runs a script and closes the window without confirmation that it has started.
Thanks in advance.
here is the details of the Mongrel error:
C:\Users\Will\Desktop\instantrails\rails_apps\talewiki>mongrel_rails start -p 30
00
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment...
C:/Users/Will/Desktop/instantrails/ruby/lib/ruby/gems/1.8/gems/activerecord-2.0.
2/lib/active_record/connection_adapters/abstract/connection_specification.rb:217
:in establish_connection': development database is not configured (ActiveRecord
::AdapterNotSpecified)
from C:/Users/Will/Desktop/instantrails/ruby/lib/ruby/gems/1.8/gems/acti
verecord-2.0.2/lib/active_record/connection_adapters/abstract/connection_specifi
cation.rb:208:inestablish_connection'
from C:/Users/Will/Desktop/instantrails/ruby/lib/ruby/gems/1.8/gems/rail
s-2.0.2/lib/initializer.rb:234:in initialize_database'
from C:/Users/Will/Desktop/instantrails/ruby/lib/ruby/gems/1.8/gems/rail
s-2.0.2/lib/initializer.rb:94:inprocess'
from C:/Users/Will/Desktop/instantrails/ruby/lib/ruby/gems/1.8/gems/rail
s-2.0.2/lib/initializer.rb:49:in send'
from C:/Users/Will/Desktop/instantrails/ruby/lib/ruby/gems/1.8/gems/rail
s-2.0.2/lib/initializer.rb:49:inrun'
from C:/Users/Will/Desktop/instantrails/rails_apps/talewiki/config/envir
onment.rb:13
from C:/Users/Will/Desktop/instantrails/ruby/lib/ruby/site_ruby/1.8/ruby
gems/custom_require.rb:27:in gem_original_require'
from C:/Users/Will/Desktop/instantrails/ruby/lib/ruby/site_ruby/1.8/ruby
gems/custom_require.rb:27:inrequire'
... 9 levels...
from C:/Users/Will/Desktop/instantrails/ruby/lib/ruby/gems/1.8/gems/mong
rel-1.1.2-x86-mswin32/bin/../lib/mongrel/command.rb:212:in run'
from C:/Users/Will/Desktop/instantrails/ruby/lib/ruby/gems/1.8/gems/mong
rel-1.1.2-x86-mswin32/bin/mongrel_rails:281
from C:/Users/Will/Desktop/instantrails/ruby/bin/mongrel_rails:19:inlo
ad'
from C:/Users/Will/Desktop/instantrails/ruby/bin/mongrel_rails:19
As it appears your Database has not been configured. Check out the APP_ROOT/config/database.yml file and find if you have created the database that corresponds to the development environment. Once you setup the DB, your code should run fine.
I have a webapp that segfaults when the database in restarted and it tries to use the old connections. Running it under gdb --args apache -X leads to the following output:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212868928 (LWP 16098)]
0xb7471c20 in mysql_send_query () from /usr/lib/libmysqlclient.so.15
I've checked that the drivers and database are all up to date (DBD::mysql 4.0008, MySQL 5.0.32-Debian_7etch6-log).
Annoyingly I can't reproduce this with a trivial script:
use DBI;
use Test::More tests => 2;
my $dbh = DBI->connect( "dbi:mysql:test", 'root' );
sub test_db {
my ($number) = $dbh->selectrow_array("select 1 ");
return $number;
}
is test_db, 1, "connected to db";
warn "restart db now";
getc;
is test_db, 1, "connected to db";
Which gives the following:
ok 1 - connected to db
restart db now at dbd-mysql-test.pl line 23.
DBD::mysql::db selectrow_array failed: MySQL server has gone away at dbd-mysql-test.pl line 17.
not ok 2 - connected to db
# Failed test 'connected to db'
# at dbd-mysql-test.pl line 26.
# got: undef
# expected: '1'
This behaves correctly, telling me why the request failed.
What stumps me is that it is segfaulting, which it shouldn't do. As it only appears to happen when the whole app is running (which uses DBIx::Class) it is hard to reduce it to a test case.
Where should I start to look to debug this? Has anyone else seen this?
UPDATE: further prodding showed that it being under mod_perl was a red herring. Having reduced it to a simple test script I've now posted to the DBI mailing list. Thanks for your answers.
What this probably means is that there's a difference between your mod_perl environment and the one you were testing via your script. Some things to check:
Was your mod_perl compiled with the same version of Perl
Are the #INC's the same for both
Are you using threads in your mod_perl setup? I don't believe DBD::mysql is completely thread-safe.
I've seen this problem, but I'm not sure it had the same cause as yours. Are you by chance using a certain module for sending mails (forgot the name, sorry) from your application? When we had the problem in a project, after days of debugging we found that this mail module was doing strange things with open file descriptors, then forked off another process which called the console tool sendmail, which again did strange things with file descriptors. I guess one of the file descriptors it messed around with was the connection to the database, but I'm still not sure about that. The problem disappeared when we switched to another module for sending mails. Maybe it's worth a look for you too.
If you're getting a segfault, do you have a core file greated? If not, check ulimit -c. If that returns 0, your system won't create core files and you'll have to change that. If you do have a core file, you can use gdb or similar tools to debug it. It's not particularly fun, but it's possible. The start of the command will look something like:
gbd /usr/bin/httpd core
There are plenty of tutorials for debugging core files scattered about the Web.
Update: Just found a reference for ensuring you get core dumps from mod_perl. That should help.
This is a known problem in old DBD::mysql. Upgrade it (4.008 is not up to date).
There's a simple test script attached to https://rt.cpan.org/Public/Bug/Display.html?id=37027
that will trigger this bug.