Home » RADICORE development » Workflow » Problem with db
| Problem with db [message #18] |
Wed, 19 April 2006 16:07  |
augustin
Messages: 7
Registered: April 2006
|
Junior Member |
|
|
I got this message:
This application has encountered an unrecoverable error
The following has been reported to the administrator:
2006-04-19 22:06:15
Fatal Error: MySQL error: 1044 : Access denied for user: 'augustin@localhost' to database '****audit' (# 256).
Error in line 47 of file '/home/httpd/vhosts/augustin.it/httpdocs/radicore/includes/d ml.mysql.class.inc'.
Script: /radicore/menu/logon.php
Remote Address: 84.87.84.59
Request URI: /radicore/menu/logon.php
Warning: error_log(../errorlog.html): failed to open stream: Permission denied in /home/httpd/vhosts/augustin.it/httpdocs/radicore/includes/er ror.inc on line 156
I have configure a mysql database with the name augustin.
I have entered the login name and password at the config.inc
} else {
// this is for my shared web host
$GLOBALS['dbusername'] = 'xxxxxx';
$GLOBALS['dbuserpass'] = 'xxxxxx';
it looks like your program finds a database called '****audit'
where can i config the database name?
Many thanks again
Erik
|
|
|
|
| Re: Problem with db [message #19 is a reply to message #18] |
Wed, 19 April 2006 16:42  |
AJM
Messages: 2371
Registered: April 2006
Location: Surrey, UK
|
Senior Member |
|
|
(a) It sounds like you have left the line $GLOBALS['dbprefix'] = '****';
(b) You cannot change the names of the various databases. You must keep the names that are supplied in the various sql scripts as they are not configurable.
(c) The file ../errorlog.hml is used to to store error messages, therefore you need to ensure that the application has write access to it.
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
|
|
| Re: Problem with db [message #21 is a reply to message #20] |
Thu, 20 April 2006 04:28 |
AJM
Messages: 2371
Registered: April 2006
Location: Surrey, UK
|
Senior Member |
|
|
The database name is "audit", not "rad_audit". There is no "rad_" prefix on any of my database names.
The only time you need to use $GLOBALS['dbprefix'] in the CONFIG.INC file is when you are installing the framework on a shared server and all your database names are prefixed with your account name. For example, on my home PC the database name is "audit", but on the shared server where my account name is "radicore" it is known as "radicore_audit".
The value in $GLOBALS['dbprefix'] is then referenced within the framework code and used as and when necessary, so it only needs to be defined in one place.
If you are not using a shared server which forces your database names to have a prefix, then don't define a prefix. It's as simple as that.
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
|
|
| Re: Problem with db [message #24 is a reply to message #22] |
Thu, 20 April 2006 15:36 |
AJM
Messages: 2371
Registered: April 2006
Location: Surrey, UK
|
Senior Member |
|
|
I have ever heard of the restriction that you cannot use the same userid/password on more than one database. Indeed, it is common practice to allow just the opposite. You connect to the database server using a single login, and within that connection you can access as many databases (or 'schemas' in PostgreSQL) as you like. You can only supply different login details by making an additional connection, and you cannot perform JOINS across multiple connections.
This idea would also prevent connection pooling where a database connection is not closed, just suspended, so that when a process wants to talk to the database it simply picks up a suspended connection and avoids the overhead of creating a new one.
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
|
|
| Re: Problem with db [message #1002 is a reply to message #1001] |
Sat, 28 July 2007 11:50 |
AJM
Messages: 2371
Registered: April 2006
Location: Surrey, UK
|
Senior Member |
|
|
I'm afraid that Radicore was designed as a modular system, and each module uses its own database with hard-coded database names. The amount of effort required to re-engineer all that code just to satisfy the feeble requirements of amateur web hosting companies is not something I am prepared to do.
If your ISP does not allow more than one database then I can only suggest that you switch to a different ISP who is prepared to offer a more professional level of service.
I have also heard of some ISPs who refuse to load optional extensions such as XML and XSL, which makes using Radicore impossible. That is not my problem, it is an ISP problem.
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
| Re: Problem with db [message #1003 is a reply to message #18] |
Sat, 28 July 2007 14:06 |
zamolxes
Messages: 9
Registered: July 2007
Location: Transilvania, Romania
|
Junior Member |
|
|
I suggest you directly tell that amateur ISP company, what it will take them to become professionals.
You'll find them at http://www.unitedinternet.de
Unless you are fluent in German, press the 'English' button on the top right. There is a mail adress in the imprint where you can contact them. I am very interested what they will reply.
They host several million web users, (including many major companies from Germany) and claim to be the world's largest web hoster. Of course database creation there is not done by hand and naming conventions follow the standards they have developped.
I do not (yet) know how rigid their naming policy is, but if they adhere to their principles and you adhere to yours, this will mean, that none of their several million customers will ever be able to use Radicore, nor will I.
If you don't plan to have Radicore deployed at a larger scale, but have its use confined to those ISPs who happen to be compatible with your design principles, and if you are more than happy with your income generated from this source, then this may not be an issue for you.
Otherwise a little bit of reconsideration might be in place.
HF
|
|
|
|
| Re: Problem with db [message #1004 is a reply to message #1003] |
Sat, 28 July 2007 15:02 |
AJM
Messages: 2371
Registered: April 2006
Location: Surrey, UK
|
Senior Member |
|
|
Popular databases such as MySQL, PostgreSQL and Oracle allow multiple database schemas per connection, and the Control panel software used by most of the ISPs that I have seen specifically allow multiple databases with whatever names you want, as does the popular phpMyAdmin administration tool. Those ISPs who specifically disallow multiple databases are, in my experience not offering a professional service, so I do not want to waste any of my valuable time in modifying my software so that it runs in their cheap, amateur environment.
I am not bothered about the potential loss of revenue that this may cause as I have more than enough projects from professional companies wh consider multiple databases to be a normal setup.
I'm sorry if you find my views inconsiderate, but perhaps you could as your ISP to explain their single database restriction. This is an artificially imposed limitation which has nothing to do with any software, so they should justify why they have imposed it.
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
|
|
| Re: Problem with db [message #1006 is a reply to message #1005] |
Sat, 28 July 2007 17:20 |
AJM
Messages: 2371
Registered: April 2006
Location: Surrey, UK
|
Senior Member |
|
|
It is possible to merge all the tables into a single database, but the effort is too huge and I'm not going to do it. I have been working on large applications for many years, and the concept of a separate database for each subsystem is just standard practice. This is how professinal systems are written, it is how professional databases work, so low budget ISPs should not prevent the standard practice of professionals with their amateur restrictions.
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
| Re: Problem with db [message #1007 is a reply to message #18] |
Sat, 28 July 2007 20:42 |
zamolxes
Messages: 9
Registered: July 2007
Location: Transilvania, Romania
|
Junior Member |
|
|
"It is possible to merge all the tables into a single database, but the effort is too huge and I'm not going to do it."
If merging the tables into one database involves considerable work from your part, why do you write such misleading things in your Programming Guidlines, that lead to the conclusion, that it can be achieved by configuration.
"I have been working on large applications for many years, ..."
So have I, really complex applications, able to cope with terabytes of information under very stringent conditions as to performance, accuracy, timeliness, requiring exact design.
"... and the concept of a separate database for each subsystem is just standard practice. This is how professional systems are written, it is how professional databases work, ..."
Experience shows, that there is no such thing as 'standard practice'. Instead, there exist quite a number of standard practices, each in its own right, and applied according to circumstances.
According to Charles Darwin neither the most intelligent, nor the strongest will survive, but the most adaptable. This is also true for software.
The professionality of a software product is unrelated to the size of he application for which it is used. From what you say, I conclude that only large applications can be professional.
However ingeniously a product may be designed, its acceptance and success will strongly depend on its ability to adapt itself to the most controversial environments.
"... so low budget ISPs should not prevent the standard practice of professionals with their amateur restrictions."
Why don't you tell the ISPs? I'm not an ISP and telling ME what ISPs should do, or rather what they should not do, will not bring about changes.
In the meantime, could you answer these questions? If I try to have Radicore installed on one of our systems over which I have complete control, how much space should be allocated for each of the different databases? I have not read all your documentaion yet, but before I end up with another surprise, I rather ask this question now, and I'm asking it because after all I have read now, Radicore is oriented towards utmost professionalism: Will I have to distribute these databases over separate disks, since this is how professional databases work? And if so, can those disks be shared with other applications, or must they be dedicated to Radicore? This will help me estimate the number of hard disks I'll possibly have to buy, in order to make the framework run.
Best regards HF
|
|
|
|
| Re: Problem with db [message #1009 is a reply to message #1007] |
Sun, 29 July 2007 15:34 |
AJM
Messages: 2371
Registered: April 2006
Location: Surrey, UK
|
Senior Member |
|
|
Here are my answers:
- There is nothing in my programming guidelines which says that my software can be switched from using multiple databases to a single database with a simple configuration option.
- The comment in my programming guidelines about "where there is a restriction on the number of different databases which can be created" was for ADDITIONAL databases for new subsystems being written to run under the Radicore framework as I am aware that some ISPs do not allow more than 5 or so databases. The kind of people who will most likely benefit from using the Radicore framework are the ones who have total control over their web servers, so the petty restrictions imposed by some low-budget ISPs are of no concern to me.
- I have been writing administrative applications, primarily for the desktop and latterly for the web, for over 25 years. These applications involve heavy database usage, and it was standard practice in all of those applications to have separate databases for each subsystem. Thus to me this is "standard practice". My current project, for example, has 7 databases, 130 tables, 230 relationships and 1000 tasks.
- Databases such as MySQL, PostgreSQL and Oracle specifically allow multiple database schemas per server, it is possible for a single SELECT statement to access multiple databases through the use of JOINs, and their administration tools make the maintenance of multiple databases/schemas very easy. Any ISP who specifically disallows this capability is, IMHO, providing a less-than-optimal service.
- The databases within the Radicore framework are quite small, initially less than 2MB combined, and the only one which may grow significantly over time is the Audit database, but that depends entirely on how much data you write to it. If you ever reach any limits on database sizes it will not be as a result of a flaw in the Radicore framework.
- The Radicore framework does not FORCE you to distribute each database onto a separate server, neither does it disallow it. It even allows different databases to run under different databases engines, so you can have a MySQL database, a PostgreSQL database and an Oracle database all running under a single Radicore instance.
- The Radicore framework does not mind sharing a disk with other applications, and it will allow both the application code and the database(s) to reside on the same disk, therefore the minimum number of hard disks is 1 (one). There is no maximum.
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
|
|
| Re: Problem with db [message #1013 is a reply to message #18] |
Mon, 30 July 2007 19:26 |
zamolxes
Messages: 9
Registered: July 2007
Location: Transilvania, Romania
|
Junior Member |
|
|
Thanks for the time you took for giving accurate answers.
Of course with 1and1 there are alternatives that allow for more sophisticated database layout. My tariff includes 10 MySQL databases. However in order to have complete control over naming, I would have to move from web hosting to managed server, and this is something I am not really enthusiastic about.
I will check out the possibilities I have here with our local machines and then I'll sure be back in the forum.
HF
|
|
|
|
| |
  |
Goto Forum:
Current Time: Fri Nov 29 00:24:51 EST 2024
Total time taken to generate the page: 0.01406 seconds
|
Radicore Forum
Search
Help
Members
Register
Login
Home
