Leaderboard

Indeed, that seems to be more disturbing than the outage itself.

No it is not. Guys, just take a look at the PHP exception trace. More specifically, the line that reads "LoadBalancer->getConnection(0,Array,false)", that's where the shit hits the fan. That line triggers a "connection refused" exception. One of the servers which the load balancer can choose from in this array is inaccessible. Not all of them are inaccessible because when you press F5 often enough in your browser the load balancer will sooner or later hit one that works. So this is a simple web site management issue. The person in charge should simply remove broken db servers from the list which the load balancer uses to choose from. So... Why the heck does Idera not manage this properly?

I assume they would care very much as soon as one (or a few) of the big customers would say to fix it before they pay their yearly fee. Eh, no big bucks in community itself. Probably many of you guys who are part of bigger teams (2 developers and up 🙂 ) can say that rarely the whole team cares about stuff like that. 100% of my team is not happy about stuff like that is not shy about voicing it. But, my team is just me. If one of the bigger teams would voice dissatisfaction to their bosses, as a whole team, perhaps they can move some stuff.

I thought he was just continuing a joke.

16th during the webinar we should all ask the question whenever the future of Delphi includes some kind of online documentation or not. I believe that will be the perfect place to ask!

The person responsible is sitting in Australia, the access to the server is only available during business hours in California and needs the approval from somebody in Europe. And the server does not have a reset button because that would be a security risk. 😉

As the free plan is limited to 50 entries, I redirected an existing monitor to the new URL () then turned it on. My guess is that even while the old URL was turned off off, it was counted as "up", and reflected in these numbers. The numbers are already going down, as while writing it is this from the ~53% you noticed: --jeroen

The MySQL uptime and the connection to are still responsibilities of the IT department. Anyway: made it UptimeRobot watch a deeper link which is now available at https://stats.uptimerobot.com/3yP3quwNW/780058619 for anyone to keep an eye on. Luckily, https://web.archive.org and https://archive.is have a lot of pages archived.

It's flaky. Again. I archived https://archive.ph/TIWRy from https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Main_Page: [8c1240dd3d6ee2e766657d26] /RADStudio/Alexandria/en/Main_Page Wikimedia\Rdbms\DBQueryError from line 1457 of /var/www/html/shared/BaseWiki31/includes/libs/rdbms/database/Database.php: A connection error occured. Query: SELECT lc_value FROM `rad_alexandria_en_l10n_cache` WHERE lc_lang = 'en' AND lc_key = 'preload' LIMIT 1 Function: LCStoreDB::get Error: 2006 MySQL server has gone away (etnadocwikidb01) Backtrace: #0 /var/www/html/shared/BaseWiki31/includes/libs/rdbms/database/Database.php(1427): Wikimedia\Rdbms\Database->makeQueryException(string, integer, string, string) #1 /var/www/html/shared/BaseWiki31/includes/libs/rdbms/database/Database.php(1200): Wikimedia\Rdbms\Database->reportQueryError(string, integer, string, string, boolean) #2 /var/www/html/shared/BaseWiki31/includes/libs/rdbms/database/Database.php(1653): Wikimedia\Rdbms\Database->query(string, string) #3 /var/www/html/shared/BaseWiki31/includes/libs/rdbms/database/Database.php(1479): Wikimedia\Rdbms\Database->select(string, string, array, string, array, array) #4 /var/www/html/shared/BaseWiki31/includes/cache/localisation/LCStoreDB.php(52): Wikimedia\Rdbms\Database->selectField(string, string, array, string) #5 /var/www/html/shared/BaseWiki31/includes/cache/localisation/LocalisationCache.php(357): LCStoreDB->get(string, string) #6 /var/www/html/shared/BaseWiki31/includes/cache/localisation/LocalisationCache.php(271): LocalisationCache->loadItem(string, string) #7 /var/www/html/shared/BaseWiki31/includes/cache/localisation/LocalisationCache.php(471): LocalisationCache->getItem(string, string) #8 /var/www/html/shared/BaseWiki31/includes/cache/localisation/LocalisationCache.php(334): LocalisationCache->initLanguage(string) #9 /var/www/html/shared/BaseWiki31/includes/cache/localisation/LocalisationCache.php(371): LocalisationCache->loadItem(string, string) #10 /var/www/html/shared/BaseWiki31/includes/cache/localisation/LocalisationCache.php(292): LocalisationCache->loadSubitem(string, string, string) #11 /var/www/html/shared/BaseWiki31/languages/Language.php(3177): LocalisationCache->getSubitem(string, string, string) #12 /var/www/html/shared/BaseWiki31/includes/MagicWord.php(352): Language->getMagic(MagicWord) #13 /var/www/html/shared/BaseWiki31/includes/MagicWord.php(280): MagicWord->load(string) #14 /var/www/html/shared/BaseWiki31/includes/parser/Parser.php(4848): MagicWord::get(string) #15 /var/www/html/shared/BaseWiki31/extensions/TreeAndMenu/TreeAndMenu_body.php(24): Parser->setFunctionHook(string, array) #16 /var/www/html/shared/BaseWiki31/includes/Setup.php(948): TreeAndMenu->setup() #17 /var/www/html/shared/BaseWiki31/includes/WebStart.php(88): require_once(string) #18 /var/www/html/shared/BaseWiki31/index.php(39): require(string) #19 {main} The main page gives a HTTP 404, but also loads https://docwiki.embarcadero.com/RADStudio/Alexandria/e/load.php?debug=false&amp;lang=en&amp;modules=ext.fancytree%2Csuckerfish|jquery.accessKeyLabel%2CcheckboxShiftClick%2Cclient%2Ccookie%2CgetAttrs%2ChighlightText%2Cmw-jump%2Csuggestions%2CtabIndex%2Cthrottle-debounce|mediawiki.RegExp%2Capi%2Cnotify%2CsearchSuggest%2Cstorage%2Cuser|mediawiki.api.user|mediawiki.page.ready%2Cstartup|site|skins.duobook2.js&amp;skin=duobook2&amp;version=149306z which delivers a nice 500. A long time ago I made https://stats.uptimerobot.com/3yP3quwNW for monitoring http(s) status in the hope they would be watching it. That one monitors the home page, but maybe I should have it monitor a sub-page like the main page for XE8 or so, as this one also gives a nice 500 error: https://docwiki.embarcadero.com/RADStudio/XE8/en/Main_Page On the other hand: from a bigger organisation like Idera, one would exepct more IT infrastructure competence (hello 24x7 monitoring!) than back in the days when just the core CodeGear DevRel team was keeping the documentation sites up and running (and by using Delphi web front-end plus InterBase database back-end provided valuable quality feed back to the R&D team). Guessing from `BaseWiki31` I guessed they might still be on MediaWiki 1.31 which was an LTS version, but is unsupported now and has been replaced by 1.35 LTS. My guess was right as in https://docwiki.embarcadero.com/ (archived as https://web.archive.org/web/20220217084835/http://docwiki.embarcadero.com/) you see this: <meta name="generator" content="MediaWiki 1.31.1"> MediaWiki versions are at: - https://www.mediawiki.org/wiki/MediaWiki_1.31 - https://www.mediawiki.org/wiki/MediaWiki_1.35 - https://www.mediawiki.org/wiki/Version_lifecycle Back in the days they were keen in advocating life cycle management. Maybe time to show they indeed still understand what that means. --jeroen

I guess 50% back. The accept cookie text should be another concern on viewing blog. https://blogs.embarcadero.com/ The cookie text reads Clicking on do not sell my personal information returns: "You really want to opt out." Hopefully this is not implicit when using the help. Since I have a subscription they have more personal information to sell.

They have the same with the Delphi IDE 🙂

Imagine not being able to get your company's website up and running again after more than a week? What an absolute joke. I guess I'll go and find my old Delphi 6 printed language guide to look up the info I can't find online rn.

Maybe they are updating it for Delphi 11.1?? Says he with a hopeful thought...

Notepad++ next 🙂

I loved Parnassus plug-ins, but the delayed updates, combined with odd DLL issues I was having when trying to manage multiple versions of Delphi while using the plug-ins and having to use Get-It forced me to un-learn my reliance on them. Usable navigation, a minimap, and improved bookmarks should all be native in the IDE at this point, IMO. As someone else mentioned, I am glad that their high-dpi updates broke these plug-ins, finally someone at Emba actually has to USE the mess that is Delphi high-DPI support. That's the only way it will ever be truly fixed.

If you're willing to install AutoHotKey, these two scripts can substitute for the Parnassus stack bookmarks: #IfWinActive ahk_class TAppBuilder ^n:: Send ^k^g return #IfWinActive ahk_class TAppBuilder Escape:: Send ^q^g return I'm using Ctrl-n to drop a marker, and Esc will collect the last marker. Works well for me.

To paraphrase a post; it now takes two MVPs to update a plug-in for D11 HighDPI..

I was signed up but didn't have time to watch it - when I tried some of the interesting replays, they were not working. Why don't they do a blog post about it and indicate a timeframe for availability? In a way, it is good that they have HighDPI issues since that means proper dogfooding, but I fear that we will be talking about update 1, and not a December hotfix. Judging from all the HighDPI issues I've seen discussed, the right thing to do would be to break the mold and do it right. The current approach with kludges and workarounds = tech debt++.

When there are reasons, there should be public information - but there is just silence.

OK - so now its about a month since Delphi 11 was releasedand still no sign of these plugins. It's not exactly a great advert for the Getit system (which was supposed to make it much easier to distribute Delphi components and addins) that even Embarcadero hasn't been able to recompile its own tools for distribution after so long. At least they released the KSVC components after a few weeks.

I did not like its stack based bookmarks as those were caret bookmarks AFAIR. So I wrote a plugin for Parnassus bookmark which turns the normal bookmarks to stack-bookmarks. Sadly the plugin API is somewhat limited so the plugin not a beauty, lot of workarounds. The only drawback it has, on closing and opening files with active bookmarks, there could be some interference which occurs sometimes. But it works for me, I'm only using only one shortcut to add/remove bookmarks, it's the ctrl-shift-1. If the bookmark "1" is nearby when I press ctrl-shift-1, it moves the bookmark, if I press it on the bookmark "5", it deletes 1-4 and 5 becomes 1 (cuts the snake) On every new "1" bookmark the others are incremented. etc... Now @David Millington gave away his plugin to embarcadero and they removed its plugin support officially. (Yes, plugin in plugin) The Plugin API was removed with its manual and its examples. Perhaps nobody knows anymore it existed. So I think there will be another 60 Years needed to have a bookmark for Delphi which makes sense. This 0-9 on every file is somewhat 80's. They should hire more innovative ppl. younger than 65. Sorry guys, but it's true.

It's an absolute disgrace. They really don't care do they ? Plenty of bugs reported already on this issue in https://quality.embarcadero.com (also by me). They tend to get closed as 'resolved' and duplicate. Must be good for the stats. I don't know what's worse, not being able to fix something like this or totally ignoring the community and not communication about it at all.

Somebody in the German Delphi Praxis claimed they are working on it. Unfortunately I don't remember who it was and whether he mentioned the source. One would expect Embarcadero to at least post a message on their site that they are aware of the problem. But on the other hand experience shows that communication from Embarcadero revolves mostly about sales.

This is really annoying. I haven't been able to access the docwiki for several days except for an occasional disambiguation page. Does anyone at Emb even known there's a problem? The issue has been reported to Emb QA (https://quality.embarcadero.com/browse/RSP-37138) but the current internal status is "Validation" which I take to mean that nobody has even bothered to try to access the site to determine if the Jira report is correct or not. This does not bode well for Embarcadero. Perhaps if more of us would access the case (use the above link) and "upvote" the issue, it would receive more attention.