[QUOTE=Robert_JD;382068]...when I submit my latest LL results, I still get this php error message:[/QUOTE][QUOTE=patrik;382070]I get the same error, and it seems (from the My Account/Results page) that the exponent is not accepted.[/QUOTE]Please PM me the result line in question, or any result line that doesn't play nice on the server.

[QUOTE=Madpoo;382069]Hmm... that might be something George needs to take a look at.
First off, we still shouldn't be showing the SQL error to the end user. :)[/QUOTE]George is in charge of that section of the code so I'll leave it for him to look at, but the code does need some checks in place to abort if (for example) the app_id isn't present for whatever reason.

[QUOTE=Madpoo;382069]James is testing a new manual submission page and looking for beta testers, so be sure to PM him if you're interested.[/QUOTE]I'm fairly certain the result line in question should work on the new page because I was testing exactly that kind of result line yesterday. Testing your result submission would be useful.

[QUOTE=Madpoo;382074]FYI, my best guess is that in the results, your client identifies itself as "CUDALucas v2.05" but in the database there's a version ID for "CUDALucas v2.05 Beta". If it's trying to lookup that internal app version id based on the text matching, then it won't.[/QUOTE]The new results-parser will create app_id entries as needed, but the old manual_results form would not; until yesterday there was only one generic entry for CUDALucas... :yzzyx: which leads me to the cause of the problem:
The old code is expecting exactly one entry in the database for CUDALucas app_id, and is getting confused when it finds two. I'll have to see about quick-patching the old code for now until the new form is vetted.

And now the old form [I]should[/I] be working again. If someone who has a CUDALucas result could please confirm for me?

And, now [url]www.mersenne.org[/url] is 404 as a whole.
I'm not sure how or if this could be related to anything I just did, but every page I try gives 404. Calling in support...

edit: 5 mins later it's working again. Not sure what that was.

[QUOTE=James Heinrich;382085]And, now [url]www.mersenne.org[/url] is 404 as a whole.
.......
edit: 5 mins later it's working again. Not sure what that was.[/QUOTE]I have gotten that on occasion in the last 2 or 3 days. It will be unavailable, then show back up a few minutes later.

[QUOTE=Uncwilly;382091]I have gotten that on occasion in the last 2 or 3 days. It will be unavailable, then show back up a few minutes later.[/QUOTE]

The temporary location of the server is in an LA datacenter, and as luck would have it, that LA datacenter has been hit with a slew of DDoS attacks in the psat month (I think some online gaming sites are colocated there, and they were the target).

It's led to some brief outages while the NOC blackholed the target of the attacks.

I'm not saying that's what happened earlier today, since I didn't get their usual email about network reconfiguration, but still...

I'll be checking the server in a bit to see if there was anything on it that might have caused a problem, but right now my real job awaits. :smile:

I can confirm that is working again now. I just submitted the result from this morning, and now it was accepted. The line in question was
[CODE]M( 36177077 )C, 0x50b953769213002a, n = 2097152, CUDALucas v2.03[/CODE]
(I assume it is safe to post it now, since the result was verified.)

[QUOTE=James Heinrich;382084]Please PM me the result line in question, or any result line that doesn't play nice on the server.

George is in charge of that section of the code so I'll leave it for him to look at, but the code does need some checks in place to abort if (for example) the app_id isn't present for whatever reason.

I'm fairly certain the result line in question should work on the new page because I was testing exactly that kind of result line yesterday. Testing your result submission would be useful.

The new results-parser will create app_id entries as needed, but the old manual_results form would not; until yesterday there was only one generic entry for CUDALucas... :yzzyx: which leads me to the cause of the problem:
The old code is expecting exactly one entry in the database for CUDALucas app_id, and is getting confused when it finds two. I'll have to see about quick-patching the old code for now until the new form is vetted.

And now the old form [I]should[/I] be working again. If someone who has a CUDALucas result could please confirm for me?[/QUOTE]

Recently ran CUDALucas 2.05, and I am happy to confirm it's working again with the results verified :-)

If all goes according to plan, the Primenet server will soon be taken down for a few hours to move the database to its new home and do some database maintenance. Thanks for your patience.

FYI, the site will be down for maintenance for the next 2 hours, give or take. It's being moved to it's new permanent home. Wish us luck!

[QUOTE=Madpoo;382129]FYI, the site will be down for maintenance for the next 2 hours, give or take. It's being moved to it's new permanent home. Wish us luck![/QUOTE]

Good Luck! :tu:

It's back. Let us know what's broken.

[QUOTE=Prime95;382145]It's back. Let us know what's broken.[/QUOTE]

Going to team results...

Warning: odbc_exec(): SQL error: [Microsoft][ODBC SQL Server Driver][SQL Server]Index 'team_id_fk' on table 't_gimps_results_log' (specified in the FROM clause) does not exist., SQL state 37000 in SQLExecDirect in C:\inetpub\www\2013\v5server\0.96_database.inc.php on line 130 Warning: odbc_fetch_row() expects parameter 1 to be resource, boolean given in C:\inetpub\www\2013\v5server\0.96_database.inc.php on line 131 Warning: odbc_fetch_row() expects parameter 1 to be resource, boolean given in C:\inetpub\www\2013\v5server\0.96_database.inc.php on line 132 Warning: odbc_free_result() expects parameter 1 to be resource, boolean given in C:\inetpub\www\2013\v5server\0.96_database.inc.php on line 136