Query builder does not open

Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it.

• NoSQLBooster Version
• Operating System (Windows/Mac/Ubuntu):
• Expected Behavior
• Actual Behavior
• How to Reproduce
• Screenshots

NoSQLBooster version: 5.1.4

Operating system: Windows 10

Expected "Show query builder..." collection context menu or the Query button

Actual (the default query is highlighted when using the button)

How to Reproduce: This is probably not easy to reproduce. This circumstances can be a bit complex. If the collection is big and maybe on a remote server, the query builder won't open. Maybe it tries to collect some metadata and gets stuck. QB for other collections on this server open. So, create a big collection (a couple of GB) with sub-collections to a remote server and try to open a query builder for it.

No screenshots.

Please follow the steps and send you log file to support@nosqlbooster.com.

1. Launch NoSQLBooster
2. Connect your MongoDB server
3. Open the log window
4. Double-click and open the collection
5. Open the query builder
6. Save the log file and email the log file to support@nosqlbooster.com. Please delete sensitive data first.

Unfortunately, log window (or the resulting log file) does not output anything on Query builder popup open whether successful or unsuccessful. But I managed to create a screen capture of the situation: https://youtu.be/_UYPPODFZ9g

Please focus to connection tree (left pane), press "CTRL+ALT+SHIFT+F7" to toggle developer toolbar, are there any logged errors?

Nothing appears to the javascript console in either case, but as now it was possible to debug the javascript a bit, I found this file frontend\misc\VisualQueryBuilder.js and there was in function showVisualQueryBuilder a switch case statement with cases 0 to 5. In successful case the steps run all the way to case 5 to return new VisualQueryBuilderDlg(t).show(). The unsuccessful case receives only cases 0 and 1.

function showVisualQueryBuilder(i, r) { 
            return tslib_1.__awaiter(this, void 0, void 0, function() { 
                var t, n; 
                return tslib_1.__generator(this, function(e) { 
                    switch (e.label) { 
                    case 0: 
                        if (t = r) 
                            return [3, 5]; 
                        e.label = 1; 
                    case 1: 
                        return e.trys.push([1, 3, , 4]), 
                        [4, new VqbParamsFetcher(!!i).execute()]; 
                    case 2: 
                        return t = e.sent(), 
                        [3, 4]; 
                    case 3: 
                        return (n = e.sent())instanceof utils_1.MbWarning ? [2, utils_1.ez.messager.alertError(n.message)] : [2, utils_1.showErrorBox(n)]; 
                    case 4: 
                        utils_1.ct2().noLicAndTrialExpires && (t.fields = t.fields.slice(0, 5).concat(
                

Could you please set a breakpoint in the second line "return tslib_1.__awaiter(this, void 0, void 0, function() {" and give me the value of the parameters(i and r)?

No difference in successful / unsuccesful cases. In function showVisualQueryBuilder(i, r) Parameter r is always undefined and i is true or undefined depending whether the builder is opened from the context menu or toolbar.

Thanks a lot. Because it cannot be reproduced locally, tracking problems like this is indeed less efficient.

Could you please set a breakpoint in the line "return new VisualQueryBuilderDlg(t).show()" and give me the value of the parameter(t)?

And, please also track the following method "return e.prototype.show = function() {" (VisualQueryBuilderDlg(t).show() method)

Yeah, a bit slow this remote correspondence based debugging. The value of t is an object containing some metadata of the collection and connection in the successful case. The unsuccessful case never gets that far and t is undefined. Only cases 0 and 1 in the above mentioned switch case statement are executed. In the successful case all of them. The VisualQueryBuilderDlg(t).show() works fine if the execution gets there (but it doesn't in the unsuccesful case).