Login Page - Create Account

Support Board


Date/Time: Tue, 25 Feb 2020 08:50:56 +0000



Your Workaround to connect old version to CQG works well; Only backfill a problem

[2019-08-03 23:25:20]
User791263 - Posts: 123 | Ending Date: 2020-02-29
Config: AMP/CQG FIX V-1957 DTS Server to separate Folder V-1488
(per your solution to upgrade CQG connect protocol requiring V1957? or later:
https://www.sierrachart.com/SupportBoard.php?ThreadID=44076#post_last
Link Corrected

I got your work-around to run by a new install V1957, allowing V-1488 to connect through V1957.
It is blazingly fast on feed and execution through the V1957.

I only have a couple of small problems:
I can't get intraday Futures or stats data to backfill into 1488 via V1957. Data just loads live from connect time, normally and mostly adequate for trading.
I read your links and about multiple instances (in own folders), and missing intraday data links.

In Live connection, all symbols feed, even without those added into V1957. For backfill, I tried adding all Symbols in the old version to the new as charts (which perhaps could be done by putting in the server intraday file update list (now empty).
The V1957 charts I added to match V1488 did backfill into V1957's .scid files, but not V1488.
Using Edit-delete and reload of a V1488 symbol while all connected--- did not work-- the file remains with 1 KB - no data.

The other issue may be whether trades may execute from V1488 through the DTS server. I'll explore that more before I ask a question. It seems like it might work.
(Some of us stuck on old version by a Version change that did not work for us-- will work on upgrading but need time, as explained).
- - - -
UPDATE:
I noticed chart messages on client attempt to download - turns red, green- says "Historical Download Skipped"
You've said your server CPU's run the same server module and handle many clients (versions?), so this should be nothing unusual. Surely just client ID, setting or symbol list error.
Date Time Of Last Edit: 2019-08-06 21:44:53
[2019-08-05 16:18:30]
Sierra Chart Engineering - Posts: 81442 | Ending Date: 2020-06-09
We will get back to you on this later today once we have time to review this in detail and get the relevant documentation together. Also the link you gave above is not correct. It is for the El Paso shooting. You can edit the post with the Edit link at the lower right.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2019-08-05 16:19:39
[2019-08-06 21:51:13]
User791263 - Posts: 123 | Ending Date: 2020-02-29
Link corrected. The other user in that thread may have an interest in this.

Some stats charts seem to backfill in the client (not sure how far back).
Stats may be from your S.C. server (which come with all packages?)

I can screenshot any setting window you need, and more carefully watch messages as connects.

No hurry- I have adequate connection to trade.
[2019-08-07 05:06:06]
Sierra Chart Engineering - Posts: 81442 | Ending Date: 2020-06-09
We apologize for the delay. We had to restore some documentation. But as we think about this, that documentation we restored here:
https://www.sierrachart.com/index.php?page=doc/FileMenu.html#FileFindSymbol_OpenChartFromAnotherInstance


would not let you pull data in 1488 from version 1957. Instead what you need to do is set the Data Files Folder in version 1488 to be the same as what 1957 is using. Refer to:
https://www.sierrachart.com/index.php?page=doc/GeneralSettings.html#DataFilesFolder

But make sure the instance in 1488 is not connected to the data feed (File >> Disconnect). The charts in version 1488 will then have their data coming from your current version installation. And then reopen your Chartbook after changing the Data Files Folder.

Stats may be from your S.C. server (which come with all packages?)
Yes.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2019-09-02 22:47:43
[2020-02-09 14:40:39]
User791263 - Posts: 123 | Ending Date: 2020-02-29
I relied on your workaround of Instance2 V1488 in its' own folder; I assumed V1488 would not be able to trade, but I needed those 56 charts, 14 spreadsheets which could not upgrade past V1488 due to version changes handling of some studies(VbP and another)caused columns shifting. Conversion would take months.

V1991 as server and trade Instance worked well. V1488 had superior region-adjust and scaling (you were too busy to look into that, and not my main reason for 1488).

I now get a "forced update" to current, saying V1488 has a feed incompatibility. When I bypass/cancel update, everything seems to work fine.

Am I forced to stop what works well even if 1488 is not used to trade?
(I may update Inst-1 V1991 to V2018+, sticking with 32 Bit a year or so; Recompile is a hassle.)

For a long time, SC users could use old versions when necessary (though some risks of minor bugs) Many were using years-old versions.

Did sub-instance core data feed change so much it forces a new version? We realize the "front end" trading instance must be near-current.

Can't you keep some circa V2018 server-portion with newer everything else?
(like my current set up)

Does this forced upgrade assume only a Main trading instance?

Some users had no choice or preferred older versions. We know we can't go on for 5 years, but force to current Vers for sub-instance feels like Microsoft's forced Win10 push.
[2020-02-10 02:16:52]
Sierra Chart Engineering - Posts: 81442 | Ending Date: 2020-06-09


For a long time, SC users could use old versions when necessary (though some risks of minor bugs) Many were using years-old versions.
This is no longer going to be the case. You cannot rely on this.

The most recent forced update of versions which are older has to do with logon security which benefits the user base now that we offer web-based trading.

Also Sierra Chart is not like Microsoft products. Newer versions, continue to be like older versions, with only improvements. It is not common there are affecting changes and when there are, they are easily adapted.

V1488 had superior region-adjust and scaling (you were too busy to look into that, and not my main reason for 1488).
We do remember your post on this, and we have yet to release our response because it is full of so many questions and required a more careful technical review. But in general, most of what you were saying was not even valid to begin with or the current behavior is stable and logical.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-02-10 02:17:30
[2020-02-10 03:40:26]
User931283 - Posts: 53 | Ending Date: 2017-10-31 [Expired]
My post was not about region-adjust nor scaling. Sorry I mentioned that, irrelevant to the current question:

Why would a sub-instance in a different folder logging onto V1991 have the same outside security and log on exposure as external logon is handled only once, entirely by front-end V1991?

Urging an update is understandable, but forcing it without notice if a system works, when you know I'm "stuck" a while in sub-instance pretty much destroys 3 years of work. I can't revise it now.

V1488 handshakes to V1991 which is already logged on with the same user-pw. V1991 simply authenticates the same user, no?
I'm putting 1488 in a hardware subnet. (I should have started a new thread as a new issue under the broker SC acct. Oops-- I'm on the SC account, sorry.)
Date Time Of Last Edit: 2020-02-10 03:49:49
[2020-02-10 21:02:04]
User791263 - Posts: 123 | Ending Date: 2020-02-29
I'm reposting #7 via broker acct, simplified:
A) I got scaling to mostly-work by fixing each study for 2 days, so don't worry about it. I'll get by with much-slower region adjust.

B) I understand why a Main instance must be newest logon.

Doesn't a sub-instance work through the main instance logon to enable another socket when Instance2 does not trade? The main instance handles all trades and auto trade,

You suggested the Instance2 Folder work-around so I and likely some other users could "get by" for a while.

An every-5-seconds message is too much.
"Your current service package [1488] does not support the Spreadsheet System for Trading study. | 2020-02-10

V1488 works OK as I view it now. So please, give us some option for this special "read only" via Main Instance use.
[2020-02-11 05:56:21]
Sierra Chart Engineering - Posts: 81442 | Ending Date: 2020-06-09
We have extensively communicated with you over the last couple of years, about the new functionality to resolve the problem you have. We added functionality specifically in response to that. And we also have explained the procedure to make the necessary changes over time.

A notice about the discontinuing of older versions has been out for a year, but maybe not continuously but certainly has been present for the last two months.

Each installed instance of Sierra Chart, even a sub instance, logs in independently.

If you can still use an older version that is fine, we really cannot prevent this message in an older version:

"Your current service package [1488] does not support the Spreadsheet System for Trading study. | 2020-02-10

Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-02-11 05:58:36
[2020-02-11 13:56:24]
User791263 - Posts: 123 | Ending Date: 2020-02-29
You said convert to express relative references instead of column letters in 14 spreadsheets, and rewrite page-long formulas in about 150 columns, against about 1100 studies-columns shifted by your changes to what had worked perfectly. That's a near-impossible task and unworkable, making fixes/improvements impossible, much too error-prone in a large "funnel" hierarchy.

Respectfully, that cost me 6 months to write a compressed instance-1 (38 charts) to make your work-around work, finally-- then when all was working together, you disable it.

Setting Data/Trade settings to not allow trading in 2nd instance, with SC Data feed and Symbols already-- could eliminate any need for a 2nd instance to communicate with the broker (i.e. strictly SC server fed)

Saying how much you've done (2 fixes? I do appreciate the long time/efforts)-- does not solve this-- like below
for likely 100+ of your users:

Have Instance-1 eliminate broker contact for sub-instances < V1900 and set to "not allow trading"? Or, a Data/Trade setting in Instance 1:
"Serve Read-only"
Edited: The sub-instance seems to be doing almost what I suggest,(except one chart), and unwanted attempt to install latest,and 5-second message above.
Date Time Of Last Edit: 2020-02-11 18:40:33
[2020-02-14 23:17:22]
Sierra Chart Engineering - Posts: 81442 | Ending Date: 2020-06-09
Respectfully, we no longer have any acceptance of what you are saying. It is not proper to be posting this here any longer.

We are working to make Sierra Chart a well engineered product and improving performance. And we cannot continue to support very old versions.

Make the changes that you need to. It is not going to take you six months. You could hire someone to do this on upwork, and explain the task in a structured way and it can be done in a couple of weeks. Certainly less than a month. And not even full-time work.

Why is it when this method has been available for 7+ years, you did not use it to reference study columns:
https://www.sierrachart.com/index.php?page=doc/WorkingWithSpreadsheets.php#ReferencesStudySubgraphColumnsSpreadsheetStudy

We understand the core problem and have a solution available for 7+ years. Plus additional functionality related to the insertion of blank columns.

You have no reasonable position here whatsoever.

Please do not post further about this.

We have gone out of our way to help you. And all we get is further complaints.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-02-14 23:18:50
[2020-02-14 23:37:47]
Sierra Chart Engineering - Posts: 81442 | Ending Date: 2020-06-09
And one thing we have lost track of, which should be an obvious solution in your case is this setting:
https://www.sierrachart.com/index.php?page=doc/ChartStudies.html#StudySettings_IncludeInSpreadsheet

By enabling and disabling this setting for study Subgraphs as needed for any study which has changed in regards to the number of Subgraphs, you can get it output the number of Subgraphs as previously.

And this recently added Input is something that we can make controllable per study:
https://www.sierrachart.com/index.php?page=doc/SpreadsheetStudyInputs.html#BlankColumnsAfterEachStudy

So really you have a solution right now and we have given another item we can help you with in regards to the Input listed above.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-02-14 23:40:58

To post a message in this thread, you need to login with your Sierra Chart account:

Login

Login Page - Create Account