Pages: 1 [2] 3 4 5 6 7 8 9 10 11 .. 11 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Tiberius Zol
26
|
Posted - 2014.08.02 17:49:00 -
[31] - Quote
Dragonaire wrote:Clean install is best. All the APIs are on by default so as long as the class for that API has been done it'll work. Make sure when you add your info to utilRegisteredKey that isActive = 1 or the only thing you will see is the account stuff since basically it's hardwired on for account/APIKeyInfo and account/Characters. If it still doesn't seem to be working check the log files. log/yapeal.log and log/error.log should be helpful. If there's no error.log file that's normal but if it exist there something more troubling going on. As always make sure the cache directory is writable.
All entries in utilRegisteredKey are active but still no entries in the db. Theres no error.log. Have set logging to INFO (100) and found some weired entrys in my log now like:
[2014-08-02 19:32:58] yapeal.DEBUG: Starting autoMagic for Char/MarketOrders [] [] [2014-08-02 19:32:58] yapeal.DEBUG: SELECT ac."characterID",urk."keyID",urk."vCode" FROM "db_eve"."accountKeyBridge" AS akb JOIN "db_eve"."accountAPIKeyInfo" AS aaki ON (akb."keyID" = aaki."keyID") JOIN "db_eve"."utilRegisteredKey" AS urk ON (akb."keyID" = urk."keyID") JOIN "db_eve"."accountCharacters" AS ac ON (akb."characterID" = ac."characterID") WHERE aaki."type" IN ('Account','Character') AND urk."isActive"=1 AND (urk."activeAPIMask" & aaki."accessMask" & 4096) <> 0 [] [] [2014-08-02 19:32:58] yapeal.INFO: No active characters found [] []
Why does it say: No active characters found?
|
Tiberius Zol
26
|
Posted - 2014.08.02 18:04:00 -
[32] - Quote
Ok think i found the problem. activeAPIMask is NULL by default. After i set all activeAPIMask like accessmask in accountAPIKeyInfo it seems to fetch all the stuff. |
Xynen
0
|
Posted - 2014.08.02 19:10:00 -
[33] - Quote
Dragonaire wrote:I now need some input on which APIs people want to see done next so I've decided to try to get some. I'm calling it the 'Vote for your most needed API' campaign.
For me it would be: corp/Contracts corp/StarbaseList corp/AssetList
|
Legedric Striker
Blue Republic RvB - BLUE Republic
31
|
Posted - 2014.08.03 09:30:00 -
[34] - Quote
Well, I've got some trouble to get the character sheet for one of my characters which never has been in a player corp, ever:
Quote:[2014-08-03 09:14:32] yapeal.DEBUG: Started network retrieve for char/CharacterSheet [] [] [2014-08-03 09:14:32] yapeal.DEBUG: Started XSD validating [] [] [2014-08-03 09:14:32] yapeal.DEBUG: Element 'cloneName': This element is not expected. Expected is ( allianceName ). [] [] [2014-08-03 09:14:32] yapeal.WARNING: The data retrieved from Eve API char/CharacterSheet for 93717778 is invalid [] []
The specific XML looks like this: Edit: Meh, forums don't allow xml in here as they think it's HTML... Replaced all the tag brackets...
Quote:*characterID*yyyyyyy*/characterID* *name*xxxxxxx*/name* *DoB*2013-08-09 11:38:12*/DoB* *race*Amarr*/race* *bloodLine*Amarr*/bloodLine* *ancestry*Wealthy Commoners*/ancestry* *gender*Female*/gender* *corporationName*Royal Amarr Institute*/corporationName* *corporationID*1000077*/corporationID* *cloneName*Clone Grade Iota*/cloneName* *cloneSkillPoints*9800000*/cloneSkillPoints* *balance*180000.00*/balance* *attributeEnhancers key="bonusName" columns="augmentatorValue,augmentatorName,bonusName"/* Join R-v-B-- The MOST active PVP community in EVE! |
Dragonaire
Here there be Dragons
56
|
Posted - 2014.08.03 17:22:00 -
[35] - Quote
Legedric Striker - You may have found a bug in the API actually because it's not suppose to matter if char is or has been in an alliance or faction it suppose to return some defaults like 0. I'll look at working around it as it'll probably effect any char that is in an NPC corporation since they don't have alliances or factions normally. I'll create an issue on GitHub and do a fix for it.
https://github.com/Dragonrun1/yapeal/issues/30 Finds camping stations from the inside much easier. Designer of Yapeal-á for the Eve API. Check out the Yapeal PHP API Library thread for more information. |
Dragonaire
Here there be Dragons
56
|
Posted - 2014.08.03 17:28:00 -
[36] - Quote
So just looking at the voting so far it seems AssetList needs to be the next one I work on which somehow didn't surprise me as it both very useful in most application and of course one of the harder API to program which is why it's not done yet Do continue to vote if you haven't because after doing AssetList I'll need to decided on what to do next. Finds camping stations from the inside much easier. Designer of Yapeal-á for the Eve API. Check out the Yapeal PHP API Library thread for more information. |
Jack Haydn
Valar Morghulis. Goonswarm Federation
52
|
Posted - 2014.08.03 18:38:00 -
[37] - Quote
Good work dragonaire, appreciate it. I haven't yet tested the new branch, but here's two points of feedback from the old versions:
- The "run the api every minute" concept is good, but yapeal should come with its own locking mechanism then. If you are working with a huge amount of keys (several dozen full keys), the api run will definitely be longer than 1 minute. Multiple instances running at the same time results in really weird behavior, due to DB locks, API caches ignored and stuff like that. Right now, we manually need to place a lock file in a folder, check for that before running and only proceed if the lock file doesn't exist (thanks to Somer for that tip). I think yapeal should come with this functionality ootb.
- IIRC, the standard class only provides methods to add and disable APIs. It would be really great if yapeal came with a native method to actually delete APIs. Especially in setups with a huge amount of APIs stored and a high fluctuation of APIs being deleted/invalidated, keeping the DB clean and not just isActive = 0'ed would be much appreciated. |
Dragonaire
Here there be Dragons
56
|
Posted - 2014.08.03 19:18:00 -
[38] - Quote
Actual Yapeal does locking on a per API basis which allows multiple instances to run without stepping on each others toes just like it always has for a long time. AbstractCommonEveApi::gotApiLock() handles getting the lock. Using the database for locking is faster plus more cross platform compatible for what it needs. It also using transactions for all deletes and upsert so it makes sure multiple table APIs are updated correctly and keeps everything ACID. So you shouldn't need to do any extra locking in your crontab. You said it would cause weird behavior, have you actually experienced this or just assumed because you didn't see any locking that it would?
I'm a little puzzled by what you mean when you say 'delete APIs' maybe you can explain what you mean just a little more. Finds camping stations from the inside much easier. Designer of Yapeal-á for the Eve API. Check out the Yapeal PHP API Library thread for more information. |
Kolb
Novaku Inc Novaku Alliance
3
|
Posted - 2014.08.03 19:23:00 -
[39] - Quote
Dragonaire wrote: Kolb - About the segfault are you sure you are using PHP 5.4? Try running 'php --version' to check. Also if you can copy it for us here so we can see it or better yet open issue on GitHub with it and any log files were I can take a look at what's going on should be able to figure it out.
PHP 5.5.3-1ubuntu2.3 (cli) (built: Apr 4 2014 01:10:38) Copyright (c) 1997-2013 The PHP Group Zend Engine v2.5.0, Copyright (c) 1998-2013 Zend Technologies with Zend OPcache v7.0.3-dev, Copyright (c) 1999-2013, by Zend Technologies
here's my log dump.
http://pastebin.com/FimrH7Jc |
Tiberius Zol
26
|
Posted - 2014.08.03 19:42:00 -
[40] - Quote
Dragonaire wrote:So just looking at the voting so far it seems AssetList needs to be the next one I work on which somehow didn't surprise me as it both very useful in most application and of course one of the harder API to program which is why it's not done yet Do continue to vote if you haven't because after doing AssetList I'll need to decided on what to do next.
\o/ after AssetList is implemented, I can switch my whole project to the new version. |
|
Dragonaire
Here there be Dragons
56
|
Posted - 2014.08.03 20:33:00 -
[41] - Quote
Kolb - I would assume from the all default_time_zone warnings that you are using Ubuntu and they still haven't figured out like all the other distros how to set the time zone correctly in php.ini . You probably need to fix that yourself and I'll look at adding something into Yapeal to also take care of it for it's needs. I thought I already had it setting it but must not have made it in like I thought.
On the segfault looks like you're simple running out of memory with even less than 1000 row inserts so you might want to make sure your memory_limit is high enough in php.ini. 32MB should be enough but my current setting is 128MB here on my test machine. I've not done any really memory profiling on Yapeal this time but I've used best practices to keep it as small as possible with the limit of course being the size of the Eve API XML itself. One reason I limit individual upserts to under 1001 row is to try keeping memory use lower plus work around some limits with typical MySQL setups. Finds camping stations from the inside much easier. Designer of Yapeal-á for the Eve API. Check out the Yapeal PHP API Library thread for more information. |
Kolb
Novaku Inc Novaku Alliance
3
|
Posted - 2014.08.03 20:51:00 -
[42] - Quote
Dragonaire wrote:Kolb - I would assume from the all default_time_zone warnings that you are using Ubuntu and they still haven't figured out like all the other distros how to set the time zone correctly in php.ini . You probably need to fix that yourself and I'll look at adding something into Yapeal to also take care of it for it's needs. I thought I already had it setting it but must not have made it in like I thought. On the segfault looks like you're simple running out of memory with even less than 1000 row inserts so you might want to make sure your memory_limit is high enough in php.ini. 32MB should be enough but my current setting is 128MB here on my test machine. I've not done any really memory profiling on Yapeal this time but I've used best practices to keep it as small as possible with the limit of course being the size of the Eve API XML itself. One reason I limit individual upserts to under 1001 row is to try keeping memory use lower plus work around some limits with typical MySQL setups.
I sorted all the defaults timezones out, but in my .ini I already had
; Maximum amount of memory a script may consume (128MB) ; http://php.net/memory-limit memory_limit = 128M
I doubled it to 256 but it's still
[2014-08-03 20:48:50] yapeal.DEBUG: Started filesystem retrieve for corp/WalletTransactions [] [] [2014-08-03 20:48:50] yapeal.DEBUG: Started XSD validating [] [] [2014-08-03 20:48:50] yapeal.INFO: Have 838 row(s) to upsert into corpWalletTransactions table [] [] Segmentation fault (core dumped) |
Kolb
Novaku Inc Novaku Alliance
3
|
Posted - 2014.08.03 20:54:00 -
[43] - Quote
Just to test it out I even tried setting it to no limit -1 same problem.
|
Dragonaire
Here there be Dragons
56
|
Posted - 2014.08.04 16:09:00 -
[44] - Quote
So did a little more research on seg-faults in PHP and seem what's going on is you're hitting a bug in PHP itself or one of it's extensions. Based on the log messages just before it happens I'd say there are one of 2 possible things that can be causing it.
- The preg_replace() on line 91
- PDO prepare() or execute() on lines 97-99
Since the message the preg_replace() is creating is never shown it the most likely cause but there is a small chance that it doesn't get written to the log before PHP seg-faults and aborts the background OS I/O process. Easy way to find out is to just comment out lines 91-93 where it's creating and trying to log the message and see if it stops seg-faulting. Finds camping stations from the inside much easier. Designer of Yapeal-á for the Eve API. Check out the Yapeal PHP API Library thread for more information. |
Kolb
Novaku Inc Novaku Alliance
3
|
Posted - 2014.08.04 19:54:00 -
[45] - Quote
Dragonaire wrote:So did a little more research on seg-faults in PHP and seem what's going on is you're hitting a bug in PHP itself or one of it's extensions. Based on the log messages just before it happens I'd say there are one of 2 possible things that can be causing it in the EveApiToolsTrait.php file.
- The preg_replace() on line 91
- PDO prepare() or execute() on lines 97-99
Since the message the preg_replace() is creating is never shown it the most likely cause but there is a small chance that it doesn't get written to the log before PHP seg-faults and aborts the background OS I/O process. Easy way to find out is to just comment out lines 91-93 where it's creating and trying to log the message and see if it stops seg-faulting.
Commenting out those lines did stop the seg-fault; would you like a list of my modules to help narrow down the source of the problem for future reference?
|
Dragonaire
Here there be Dragons
56
|
Posted - 2014.08.04 23:31:00 -
[46] - Quote
No it's the preg_replace() causing the problem I'm sure. The default setting they use for pcre.backtrack_limit is only 100k chars and the string was trying to process I'm guessing is closer to 200k. you can try uncommenting them and increase the setting to say 1M and see if it works but I'll probably still push out another fix that just replaces it instead. I like the RegExp because it was a single line but easy enough to use something else.
https://github.com/Dragonrun1/yapeal/issues/31 Finds camping stations from the inside much easier. Designer of Yapeal-á for the Eve API. Check out the Yapeal PHP API Library thread for more information. |
Legedric Striker
Blue Republic RvB - BLUE Republic
32
|
Posted - 2014.08.05 18:41:00 -
[47] - Quote
I just encountered a very strange issue:
I uploaded my project to my webspace and I am getting the following error now: Parse error: syntax error, unexpected '[', expecting ')' in /www/htdocs/w0123f51/_libext/vendor/yapeal/yapeal/lib/Database/CommonSqlQueries.php on line 95
return sprintf( str_replace(["\n", "\r\n"], '', $sql), $this->databaseName, $this->tablePrefix, $mask );
Line 95 is ###str_replace(["\n", "\r\n"], '', $sql),###
On my local (windows) machine it's all working Join R-v-B-- The MOST active PVP community in EVE! |
Legedric Striker
Blue Republic RvB - BLUE Republic
33
|
Posted - 2014.08.06 08:09:00 -
[48] - Quote
So after about two weeks of work I just finished most parts of my project using Yapeal!
You may visit the very first version here: http://www.eve-skillplan.net/
Of course I will add and tweak some features during the next days but it is at least in state to make the site public from now on. Thanks again for this amazing library, Dragonaire!
A seperate thread for this project will follow soon. Join R-v-B-- The MOST active PVP community in EVE!
My most recent project:-á EVE-Skillplan.net - Plan your training for EVE Online |
Dragonaire
Here there be Dragons
56
|
Posted - 2014.08.06 20:50:00 -
[49] - Quote
CCP is adding new char and corp Blueprints APIs which can be seen on test server now. I've adding them to Yapeal but set isActive=0 in utilEveApi for now until they get deployed to Tranquility.
Legedric Striker - Great to see you get it out for people to take a look and glad to hear you found Yapeal useful. I've took a quick look but not had time to actually try it but I'll try to get around to that soon. Finds camping stations from the inside much easier. Designer of Yapeal-á for the Eve API. Check out the Yapeal PHP API Library thread for more information. |
Legedric Striker
Blue Republic RvB - BLUE Republic
33
|
Posted - 2014.08.07 05:55:00 -
[50] - Quote
I think I somehow ran into a problem here.
My cronjob is running the "autoMagic" every single minute now which is being completed within just a couple of seconds (< 3 seconds).
However, it does not get fresh XML from the API for at least some characters (I didn't check all).
For example, when I am calling the API for this character manually to get the character sheet I get something like this:
Quote: *eveapi version="2"* *currentTime*2014-08-07 05:42:32*/currentTime* *result* *characterID*90750214*/characterID* *name*Legedric Striker*/name* *DoB*2011-05-16 15:19:00*/DoB* . . .
When I look into the yapeal.log for the most recent entry of this character I see the following:
Quote: [2014-08-07 05:28:02] yapeal.DEBUG: Checking if cache expired on table charCharacterSheet for ownerID = 90750214 [] [] [2014-08-07 05:28:02] yapeal.DEBUG: SELECT "expires" FROM "d01b51d3"."yap_utilCachedUntil" WHERE "apiName" = 'CharacterSheet' AND "sectionName" = 'Char' AND "ownerID" = 90750214 [] [] [2014-08-07 05:28:02] yapeal.DEBUG: Expired UtilCachedUntil record found [] [] [2014-08-07 05:28:02] yapeal.INFO: select get_lock('d1ad71e33090aff96dd6883077144a5d',5) [] [] [2014-08-07 05:28:02] yapeal.DEBUG: Started filesystem retrieve for char/CharacterSheet [] [] [2014-08-07 05:28:02] yapeal.DEBUG: Started XSD validating [] [] [2014-08-07 05:28:02] yapeal.DEBUG: characterID => 90750214 [] [] [2014-08-07 05:28:02] yapeal.DEBUG: name => Legedric Striker [] [] [2014-08-07 05:28:02] yapeal.DEBUG: DoB => 2011-05-16 15:19:00 [] [] . . .
The expires datetime in the database for this record is 2014-08-06 08:15:03 (EVE time), so something like 21 hours in the past! The cache file (d1ad71e33090aff96dd6883077144a5d) has the following content in contrary to the top xml which I pulled from teh API manually:
Quote: *eveapi version="2"* *currentTime*2014-08-06 07:15:03*/currentTime* *result* *characterID*90750214*/characterID* *name*Legedric Striker*/name* *DoB*2011-05-16 15:19:00*/DoB* . . .
Of course all the other data like accountBalance etc. are outdated... It seems like even though the cachedUntil record is expired for several hours now, Yapeal doesn't pull fresh data from the API but uses the cached file over and over again instead.
I checked the CHMOD settings and it is set to 777 for all cache folders within yapeal (777 just for testing of course!). The XML itself however do have CHMOD 644, so is it possible that yapeal cannot update the cache files properly? But why are they 644 when I set 777 recursively from the top "cache" folder? Join R-v-B-- The MOST active PVP community in EVE!
EVE-Skillplan.net - Plan your training for EVE Online |
|
Tiberius Zol
27
|
Posted - 2014.08.07 08:21:00 -
[51] - Quote
Is there a way to update the DB after i downloaded the new updates via git? Without dropping existing tables? |
Kolb
Novaku Inc Novaku Alliance
3
|
Posted - 2014.08.07 12:11:00 -
[52] - Quote
Legedric Striker wrote:Of course all the other data like accountBalance etc. are outdated... It seems like even though the cachedUntil record is expired for several hours now, Yapeal doesn't pull fresh data from the API but uses the cached file over and over again instead. I checked the CHMOD settings and it is set to 777 for all cache folders within yapeal (777 just for testing of course!). The XML itself however do have CHMOD 644, so is it possible that yapeal cannot update the cache files properly? But why are they 644 when I set 777 recursively from the top "cache" folder? /Edit: So I reset all CHMOD settings to 764 for the cache folder and all files within - so the old existing files are available for updates now. But new files will still be created with 644 (of course) and so they are impossible to be updated by yapeal...
have you tried recursivly chowning the directory to www-data?
|
Legedric Striker
Blue Republic RvB - BLUE Republic
33
|
Posted - 2014.08.07 13:54:00 -
[53] - Quote
Well, I think this may be the problem for me, my hoster is running PHP 5.3 usually on this server and to activate PHP 5.5 I have to use a CGI handler in my htaccess file.
As a result, PHP is not being run as www-data but as the main FTP user so chown is set to this user for all folders recursively.
Unfortunately this is something I cannot change...
It is very strange however that yapeal can create new files without any problems but it seems like it cannot update the content of those new fiules once they are created. So the "last changed date" is changing but not the content itself as you can see above.
Other parts of my project (log4net for example) have no trouble manipulating files. Join R-v-B-- The MOST active PVP community in EVE!
EVE-Skillplan.net - Plan your training for EVE Online |
Legedric Striker
Blue Republic RvB - BLUE Republic
33
|
Posted - 2014.08.07 18:06:00 -
[54] - Quote
After some investigation I think it may not be a permission problem.
At least as far as I understand the corresponding Yapeal parts it should delete the cache file once it is expired.
Quote: $cachePath = $this->getNormalizedCachePath($data->getEveApiSectionName()); $this->checkUsableCachePath($cachePath); $cacheFile = $cachePath . $data->getEveApiName() . $data->getHash() . '.xml'; $this->checkUsableCacheFile($cacheFile); $this->prepareConnection($cacheFile); $result = $this->readXmlData($cacheFile); $this->__destruct(); if ($this->isExpired($result)) { $mess = sprintf('Deleting expired cache file %1$s', $cacheFile); $this->getLogger() ->debug($mess); @unlink($cacheFile); return $this; }
Log output:
Quote:[2014-08-07 17:55:04] yapeal.DEBUG: Checking if cache expired on table charCharacterSheet for ownerID = 90750214 [] [] [2014-08-07 17:55:04] yapeal.DEBUG: SELECT "expires" FROM "d01b51d3"."yap_utilCachedUntil" WHERE "apiName" = 'CharacterSheet' AND "sectionName" = 'Char' AND "ownerID" = 90750214 [] [] [2014-08-07 17:55:04] yapeal.DEBUG: Expired UtilCachedUntil record found [] [] [2014-08-07 17:55:04] yapeal.INFO: select get_lock('d1ad71e33090aff96dd6883077144a5d',5) [] [] [2014-08-07 17:55:04] yapeal.DEBUG: Started filesystem retrieve for char/CharacterSheet [] [] [2014-08-07 17:55:04] yapeal.DEBUG: Started XSD validating [] []
But nowhere in my log I can see "Deleting expired cache file"... so it always uses the old and way outdated cache file over and over again Join R-v-B-- The MOST active PVP community in EVE!
EVE-Skillplan.net - Plan your training for EVE Online |
Dragonaire
Here there be Dragons
56
|
Posted - 2014.08.07 18:45:00 -
[55] - Quote
Could be that some of my changes to have Yapeal do a better job of reusing the FS cache aren't right yet I'll look at it again. Finds camping stations from the inside much easier. Designer of Yapeal-á for the Eve API. Check out the Yapeal PHP API Library thread for more information. |
Legedric Striker
Blue Republic RvB - BLUE Republic
33
|
Posted - 2014.08.07 20:14:00 -
[56] - Quote
Well, as you can see I already set my log level to 100 to see the debug messages and there is no message for deleting old cache files in there and I am using a Yapeal master branch version from 2 or 3 days ago so the issue#19 fix is already included.
I also found the IsExpired function and it seems to operate just right, although I didn't have the time to debug all the way through it just now.
As I am not my own host I have no possibility to run Yapeal anywhere else than within my web server path but I will protect the complete vendor folder path and subfolders etc. using htaccess as soon as I got a stable version of Yapeal running.
I will continue with the debugging of the specific parts of Yapeal tomorrow and post here whatever I may find or not find while doing so Join R-v-B-- The MOST active PVP community in EVE!
EVE-Skillplan.net - Plan your training for EVE Online |
Legedric Striker
Blue Republic RvB - BLUE Republic
33
|
Posted - 2014.08.07 21:14:00 -
[57] - Quote
Ok so I just did some debugging for the isExpired function in FileCacheRetriever.php
It is ALWAYS return false for me as my cache files are (as said) several hours old. The reason is line 278:
Quote: if (($current + 300) <= $now) { return false;
$current (is taken from the cached XML file - which is way too old) is like shown above from yesterday in some cases and so it is always sure that "whatever time from yesterday +300 seconds" is lower than "now".
So I changed it to:
Quote: if (($current + 300) >= $now) { return false;
In addition I also changed the following lines:
Quote:if ($until >= $now) { return true; }
into:
Quote: if ($until < $now) { return true; }
I am somewhat confused as the function is called isExpired I expect it to be TRUE if the cachedUntil time is in the past, so cachedUntil <= now and not like its in the original lines... same goes for the 5 minutes minimum cache which is also obviously turned around.
I somwhere saw a function called isNOTexpired which is operating the other way round (not for cache files though) so I thing you may have mixed up the purpose of the isExpired function here with its actual code
After I uploaded the changes to my webspace the cached files are being updated again and the API is working as intended again!
Cheers and it's time for some sleep now! Join R-v-B-- The MOST active PVP community in EVE!
EVE-Skillplan.net - Plan your training for EVE Online |
Dragonaire
Here there be Dragons
56
|
Posted - 2014.08.08 04:21:00 -
[58] - Quote
Legedric Striker - Ok updated it should work correctly now. The problem I was having is when I first started writing the method I had $current and $now flipped in what they were set to and when I changed them to what they are now I didn't get them fully flipped in my mind as well so ended up with things backwards but thanks for figuring it out. I took a little different approach on minimum time which is more what I had in mind originally. It won't run into the problem you were having but still sets a minimum cache time like I was wanting. Finds camping stations from the inside much easier. Designer of Yapeal-á for the Eve API. Check out the Yapeal PHP API Library thread for more information. |
Legedric Striker
Blue Republic RvB - BLUE Republic
33
|
Posted - 2014.08.08 05:11:00 -
[59] - Quote
Great, I just updated to the most recent build of your master branch Join R-v-B-- The MOST active PVP community in EVE!
EVE-Skillplan.net - Plan your training for EVE Online |
Tiberius Zol
27
|
Posted - 2014.08.08 13:23:00 -
[60] - Quote
Please.... change the databasescript and delete the drop table stuff.. i have deleted my whole database with months of work now because installing the new branch and update the databasestuff with yc Database:Init or create something like yc Database:Update
and my provider doesn't give me a backup -.- |
|
|
|
|
Pages: 1 [2] 3 4 5 6 7 8 9 10 11 .. 11 :: one page |
First page | Previous page | Next page | Last page |