MySQL replication manager has ability to

1. Start, Stop Slave
2. Set Status of Slave

Download

License: GNU General Public License

MySQL replication manager has ability to

1. Start, Stop Slave
2. Set Status of Slave

Download

License: GNU General Public License

David Axmark, co-founder of MySQL, is in Singapore, and has allocated some free time to meet MySQL users. If you were in the Lion City, and had an afternoon free, I suggest dropping by.

When:Saturday, November 17, 2007 at 12:00 PM

Where:GeekTerminal

55 Market Street #01-01 Singapore 048941

Singapore

+65 65570098 

(Map: http://www.geekterminal.com/web/index.php?option=com_content&task=view&id=22&Itemid=41)

Technorati Tags: mysql, singapore, david axmark

A

The TelePort project is no longer under development.

This is a re-post of an article I wrote in back in August. We’re getting ready to release a new release of Javeline PlatForm at the end of this month. This release will be XForms compliant and has a lot of other new features as well. Before I start writing about that, I would like to put some attention on the communication layer aka Javeline TelePort.

—
PHPBuilder posted an article about sending a form using AJAX. This article shows how to post a simple form. But looking closely at the example, you can also see what the problem is using the plain XMLHttpRequest object and writing an implementation yourself.

First of all you to write some rather difficult javascript code. Next you need to completely …

While researching an article I came across a piece at http://www.simple-talk.com/sql/t-sql-programming/cursors-and-embedded-sql/. Basically the author says “embedded SQL” is bad — meaning developers should never put SQL in their code. Nor should they use ORM tools to generate SQL for them.

Instead, they should access everything they need through stored procedures. I have mixed feelings about this. On one hand, you have to give table-access permissions to users and then deal with the resulting security risks sounds very control-freakish to me. On the other hand, I agree that embedded code can be bad because if you change the database model in any way, you have to rewrite the procedural code that relies on the existence of the previous model.

And of course, stored procedures also help make your code more …

While researching an article I came across a piece at http://www.simple-talk.com/sql/t-sql-programming/cursors-and-embedded-sql/. Basically the author says “embedded SQL” is bad — meaning developers should never put SQL in their code. Nor should they use ORM tools to generate SQL for them.
Instead, they should access everything they need through stored procedures. I have mixed feelings about this. On one hand, you have to give table-access permissions to users and then deal with the resulting security risks sounds very control-freakish to me. On the other hand, I agree that embedded code can be bad because if you change the database model in any way, you have to rewrite the procedural code that relies on the existence of the previous model. …

So, O’Reilly’s ONLamp.com has published the “Top 10 MySQL Best Practices” at http://www.onlamp.com/pub/a/onlamp/2002/07/11/MySQLtips.html. Sadly, I find most “best practice” list do not thoroughly explain the “why” enough so that people can make their own decisions.

For instance, #3 is “Protect the MySQL installation directory from access by other users.” I was intrigued at what they would consider the “installation” directory. By reading the tip, they actually mean the data directory. They say nothing of the log directory, nor that innodb data files may be in different places than the standard myisam data directories.

They perpetuate a myth in #4, “Don’t store binary data in MySQL.” What they really mean is “don’t store large data in MySQL”, which they go into in the tip. While it’s true that there is …

So, O’Reilly’s ONLamp.com has published the “Top 10 MySQL Best Practices” at http://www.onlamp.com/pub/a/onlamp/2002/07/11/MySQLtips.html. Sadly, I find most “best practice” list do not thoroughly explain the “why” enough so that people can make their own decisions.
For instance, #3 is “Protect the MySQL installation directory from access by other users.” I was intrigued at what they would consider the “installation” directory. By reading the tip, they actually mean the data directory. They say nothing of the log directory, nor that innodb data files may be in different places than the standard myisam data directories.  More »

The built-in HQ database is PostgreSQL. Recently, users have been discovering PostgreSQL has a certain limitation: it will not execute more than 2 billion transactions between vacuums. In rare cases, an HQ built-in database can get into this state.

If this happens, the database will stop accepting connections and HQ, which needs a data store, will obviously cease to operate properly. The immediate symptom will be that users will not be able to log in to HQ and the message displayed on the screen will be The backend datasource is unavailable.

That error is not enough to say for sure that the problem is PostgreSQL avoiding wraparound failure by not accepting connections. A quick look at the hqdb.log can confirm. The telltale log entries look like this:

FATAL: database is not accepting commands to avoid wraparound data loss in database "postgres"
HINT: Stop the postmaster and …