FROM THE DESK OF ENGR. PATRICK OLAWALE MINISTRY OF PETROLEUM LAGOS NIGERIA.
DEAR SIR,
WE ARE SENDING THIS LETTER TO YOU BASED ON INFORMATION GATHERED FROM THE FOREIGN TRADE OFFICE OF THE NIGERIAN CHAMBER OF COMMERCE AND INDUSTRY. WE BELIEVE THAT YOU WOULD BE IN A POSITION TO HELP US IN OUR BID TO TRANSFER THE SUM OF FORTY-ONE MILLION,FIVE HUNDRED THOUSAND DOLLARS ($41.5M USD) INTO A FOREIGN ACCOUNT.
WE ARE MEMBERS OF THE SPECIAL COMMITTEE FOR BUDGET AND PLANNING IN THE MINISTRY OF PETROLEUM. WE ARE PRINCIPALLY CONCERNED WITH CONTRACT APPRAISALS AND APPROVAL OF CONTRACTS IN ORDER OF PRIORITIES AS REGARDS CAPITAL PROJECT OF THE FEDERAL GOVERNMENT OF NIGERIA. WITH OUR POSITIONS, WE HAVE SUCCESSFULLY SECURED FOR OURSELVES THE SUM OF FORTY-ONE MILLION, FIVE HUNDRED THOUSAND UNITED STATE DOLLARS(US$41.5M). THIS AMOUNT WAS ACCUMULATED THROUGH UNDECLARED WINFALL FROM SALES OF CRUDE OIL DURING THE RECENT WAR AGAINST S ADAM HESSEIN AND HIS ADMINISTRATION.
WHAT WE NEED FROM YOU IS TO PROVIDE A SAFE ACCOUNT INTO WHICH THE FUNDS WILL BE TRANSFERRED SINCE GOVERNMENT OFFICIALS ARE NOT ALLOWED BY OUR LAWS TO OPERATE FOREIGN ACCOUNT. IT HAS BEEN AGREED THAT THE OWNER OF THE ACCOUNT WILL BE COMPENSATED WITH US$8.3 MILLION OF THE REMITTED FUNDS, WE KEEP US$31.125MILLION WHILE US$2.075MILLION WILL BE SET ASIDE TO OFFSET EXPENSES AND PAY THE NECESSARY TAXES.
IT MAY INTEREST YOU TO KNOW THAT TWO YEARS AGO A SIMILAR TRANSACTION WAS CARRIED OUT WITH ONE MR. PATRICE MILLER, THE PRESIDENT OF CRAINE INTERNATIONAL TRADING CORPORATION AT NUMBER 135, EAST 57TH STREET, 28TH FLOOR, NEW YORK 10022 WITH TELEPHONE (212)308-7788 AND TELEX NUMBER 6731689, AFTER THE AGREEMENT BETWEEN BOTH PARTNERS IN WHICH HE WAS TO TAKE 25% THE MONEY WAS DULY TRANSFERRED INTO HIS ACCOUNT ONLY TO BE DISAPPOINTED ON OUR ARRIVAL IN NEW YORK AS WE WERE RELIABLY INFORMED THAT MR. PATRICK MILLER WAS NO LONGER ON THAT ADDRESS WHILE HIS TELEPHONE AND TELEX NUMBERS HAVE BEEN REALLOCATED TO SOMEBODY ELSE, THAT IS HOW WE LOST US$27.5M TO MR PATRICE MILLER. THIS TIME AROUND WE NEED A MORE RELIABLE AND TRUSTWORTHY PERSON OR A REPUTABLE COMPANY TO DO BUSINESS WITH HENCE THIS LETTER TO YOU, SO IF YOU CAN PROVE YOURSELF TO BE TRUSTED AND INTERESTED IN THIS DEAL THEN WE ARE PREPARED TO DO BUSINESS WITH YOU.
WHAT WE WANT FROM YOU IS THE ASSURANCE THAT YOU WILL LET US HAVE OUR SHARE WHEN THIS AMOUNT OF US$41.5M IS TRANSFERRED INTO YOUR ACCOUNT. IF THIS PROPOSAL SATISFIES YOU, PLEASE CONTACT ME STRICTLY THROUGH MY E-MAIL STATED ABOVE SO WE CAN ADVICE YOU ON THE MODALITIES OF THE TRANSACTION. ALL MODALITIES OF THE TRANSFER HAVE BEEN WORKED OUT AND ONCE STARTED WILL NOT TAKE MORE THAN 14 WORKING DAYS WITH THE ABSOLUTE SUPPORT OF ALL CONCERNED. THIS TRANSACTION IS 100% SAFE. PLEASE TREAT AS URGENT AND VERY CONFIDENTIAL. GOD BE WITH YOU AS I LOOK FORWARD TO YOUR REPLY.
BEST REGARDS.
ENGR. PATRICK OLAWALE
Hi All!
I'm getting the same "blank screen" error when accessing our online demo. My own working copy (up to date) works fine though on my machine. Is there anything wrong with the live demo? Is the config.inc.php on our live demo server the same as the default one distributed? Then I'll have a look at which directives differ in my setup.
And, can anyone else confirm this?
Regards, Garvin.
Hi all
Just played with our online demo and the problem is in
$testGD = @imagecreatetruecolor(12,12); (libraries/defines_php.lib.php3)
It produces fatal error: Fatal error: imagecreatetruecolor(): requires GD 2.0 or later in /home/groups/p/ph/phpmyadmin/htdocs/phpMyAdmin/libraries/defines_php.lib.php3 on line 67 which causes php to terminate and send blank screen.... Any solution?
Michal Cihar wrote:
Hi all
Just played with our online demo and the problem is in
$testGD = @imagecreatetruecolor(12,12); (libraries/defines_php.lib.php3)
It produces fatal error: Fatal error: imagecreatetruecolor(): requires GD 2.0 or later in /home/groups/p/ph/phpmyadmin/htdocs/phpMyAdmin/libraries/defines_php.lib.php3 on line 67 which causes php to terminate and send blank screen.... Any solution?
Thanks Michal for your fix, it works here. Another confirmation that @ does not remove all errors!
Because the demo will update later, I temporarily deactivated the GD2 code in the demo directory.
Marc
On 22.05.2003 09:14, Marc Delisle wrote:
Michal Cihar wrote:
Hi all
Just played with our online demo and the problem is in
$testGD = @imagecreatetruecolor(12,12); (libraries/defines_php.lib.php3)
It produces fatal error: Fatal error: imagecreatetruecolor(): requires GD 2.0 or later in /home/groups/p/ph/phpmyadmin/htdocs/phpMyAdmin/libraries/defines_php.lib.php3 on line 67 which causes php to terminate and send blank screen.... Any solution?
Thanks Michal for your fix, it works here. Another confirmation that @ does not remove all errors!
Because the demo will update later, I temporarily deactivated the GD2 code in the demo directory.
I just updated the demo, it is better solution :-)
Michal Cihar wrote:
On 22.05.2003 09:14, Marc Delisle wrote:
Michal Cihar wrote:
Hi all
Just played with our online demo and the problem is in
$testGD = @imagecreatetruecolor(12,12); (libraries/defines_php.lib.php3)
It produces fatal error: Fatal error: imagecreatetruecolor(): requires GD 2.0 or later in /home/groups/p/ph/phpmyadmin/htdocs/phpMyAdmin/libraries/defines_php.lib.php3 on line 67 which causes php to terminate and send blank screen.... Any solution?
Thanks Michal for your fix, it works here. Another confirmation that @ does not remove all errors!
Because the demo will update later, I temporarily deactivated the GD2 code in the demo directory.
I just updated the demo, it is better solution :-)
No it's a worst solution, because you break the auto upgrade of the demo via Robin's cron.
At least, chmod g+rw the files, but I am not sure if the cron update will work.
Marc
Michal Cihar wrote:
On 22.05.2003 09:14, Marc Delisle wrote:
Michal Cihar wrote:
Hi all
Just played with our online demo and the problem is in
$testGD = @imagecreatetruecolor(12,12); (libraries/defines_php.lib.php3)
It produces fatal error: Fatal error: imagecreatetruecolor(): requires GD 2.0 or later in /home/groups/p/ph/phpmyadmin/htdocs/phpMyAdmin/libraries/defines_php.lib.php3 on line 67 which causes php to terminate and send blank screen.... Any solution?
Thanks Michal for your fix, it works here. Another confirmation that @ does not remove all errors!
Because the demo will update later, I temporarily deactivated the GD2 code in the demo directory.
I just updated the demo, it is better solution :-)
And chgrp to phpmyadm your files.
Marc
On 22.05.2003 10:28, Marc Delisle wrote:
And chgrp to phpmyadm your files.
I ran the update script, that does this all, so it should be IMHO okay...
Michal Cihar wrote:
On 22.05.2003 10:28, Marc Delisle wrote:
And chgrp to phpmyadm your files.
I ran the update script, that does this all, so it should be IMHO okay...
-rw-r--r-- 1 nijel users 3996 May 22 06:18 defines_php.lib.php3
Marc
On Thu, May 22, 2003 at 07:56:33PM +0200, Michal Cihar wrote:
On Thursday 22 of May 2003 17:24, Marc Delisle wrote:
-rw-r--r-- 1 nijel users 3996 May 22 06:18 defines_php.lib.php3
Should be okay now, I forgot to change it after fixing conflicts on update...
It wasn't quite right. I've updated my scripts somewhat to make them work better, and do logging so that can be reviewed easily.
One request for anybody that wants to work in that directory directly: in EACH shell instance you have in that directory, before you touch ANY file, run 'umask 002'. That should ensure that the permissions are kept sufficent for the group.
Hi All!
In Bug #741256 we have a user who reports an undefined variable when using a false table in the query from tbl_properties_structure.php3. I found out this is because in read_dump.php3 the $err_url is composed this way:
$err_url = $goto . '?' . PMA_generate_common_url($db) . (($goto == 'tbl_properties.php3') ? '&table=' . urlencode($table) : '');
Why is it that only for tbl_properties.php3 the table is propagated? Will there be any errors when also allowing tbl_properties_structure in that link?
I dislike changing it without knowing why the table variable is not carried on at any time...
Regards, Garvin.
Garvin Hicking wrote:
Hi All!
In Bug #741256 we have a user who reports an undefined variable when using a false table in the query from tbl_properties_structure.php3. I found out this is because in read_dump.php3 the $err_url is composed this way:
$err_url = $goto . '?' . PMA_generate_common_url($db) . (($goto == 'tbl_properties.php3') ? '&table=' . urlencode($table) : '');
Why is it that only for tbl_properties.php3 the table is propagated? Will there be any errors when also allowing tbl_properties_structure in that link?
I dislike changing it without knowing why the table variable is not carried on at any time...
Regards, Garvin.
Garvin,
IMO this is a bug ;) Before the split of tbl_properties.php3, the code was good, but now that there are tbl_properties_..., we should check the presence of the string "tbl_properties" in $goto, like in line 25 (then, any tbl_properties_... that includes a query box would have a correct back link).
Marc
Hi all
I agree with Marc, this code probably comes from times before splitting tbl_properties.php3 into separate pages...
-
Engr. Patrick Olawale -
Garvin Hicking -
Marc Delisle -
Michal Cihar -
Robin H.Johnson