Go Back
3 Votes

Repository Projects should give the name of the schema files which have errors


Delivered

AT present, if you have a number of schemas in a repository project, the error does not say which schema has the problem.  It seems to merge everything into a temporary file and then reports that the error against that :

Severity    Code    Description    Project    File    Line    Suppression State
Error        Load terminated...unrecognized keyword found at line 37 : Fiel    Repository    C:\Projects\HGV\143607\Projects\packages\Synergex.SynergyDE.Build.11.0.1001.2582\build\Synergex.SynergyDE.Repository.targets    402    


That file and line number isn't very helpful :
    <SynergyTasks.RPS
      IntermediateOutputPath="$(IntermediateOutputPath)"
      OutputPath="$(OutputPath)"
      SchemaFiles ="@(Compile)"
      DisableRebuild="$(UseExistingRepository_)"
      MOutputName ="$(MOutputName)"
      TOutputName="$(TOutputName)"
      MOutputName2 ="$(MOutputName2)"
      TOutputName2="$(TOutputName2)"
      OutputFiles="@(CustomAdditionalCompileOutputs)"
      EnvironmentVars="$(CombinedEnvVars)"
      TargetISAM4="$(TargetISAM4)"/>

I would like to click on the error line and be taken to the line in the schema file

10 Comments | Posted by Gordon Ireland to Visual Studio Integration, Repository on 8/2/2019 12:11 PM
Marty Lewis
Hey Gordon,

You have my vote on this one. We have a tracker already logged for this functionality that you can track.

8/8/2019 7:38 PM   0  
Gordon Ireland
Thats great.  I hoep it bubbles to the top of the pile quickly.  It can take ages finding an error in a schema, even oince you know which schema it is.

I had 2 cases recxently where it said "Long" was not valid, and one where "ODBC" was not valid

I had dozens of fields with long descriptions and ODBC names.

One of the Long Descriptions was tagged "Long Descripton" and one ODBC name was tagged "ODBC Nme"

I had to comment the field defs out one by one to find this, which took 30 mins or more.

8/9/2019 9:36 AM   1  
Ace Olszowka
+1 We've encountered this as well (actually we triggered the original tracker).

8/16/2019 1:28 PM   0  
Synergex
This has been implemented in version 11.1. Note, however, if you are loading schemas in "non-reference order", there are two phases to the loading process: the parsing phase and the completion phase. Errors emitted during the parsing phase will include the filename; errors emitted during the completion phase will not. 

10/2/2019 11:13 PM   0  
Ace Olszowka
@Synergex If I understood your comment above then this ask is not completed (this ask was for the completion phase by your terminology). Can you provide the unit test that exercises this functionality for us to test?

10/3/2019 1:25 PM   0  
Marty Lewis

I think there's a little bit of semantics confusion. In Gordon's original error message, there is an "unrecognized keyword" error that is reporting a line, but does not have any file association. I would consider that an example of a parsing phase error.

Any errors that would be generated while parsing the schema source before symbol resolution are considered a "parsing phase" error. So invalid keywords, bad sizes, and other syntactical issues will now be reported with line number and file information. When building in Visual Studio, this error information is presented in the Error List window and will allow a user to quickly navigate to the source line..

The second phase of schema processing is symbol resolution, which is called the "resolution phase" or "completion phase". This is where all of the interconnected dependency elements of the structures and templates get resolved. So if I reference a non-existent template in my FIELD definition, I will get a resolution phase error that will not be accompanied by a line number. The physical file and line information has already been abandoned by this stage of processing.

Sample to follow.

10/4/2019 12:12 AM   0  
Marty Lewis

Consider the following sample files.

templates.schema:

TEMPLATE MyTemplate TYPE alpha SIZE 128 
    DESCRIPTION "Sample template"
TEMPLATE BadTemplate PARENT FakeTemplate TYPE alpha SIZE 128 
    DESCRIPTION "Sample template"

structures.schema: 
STRUCTURE struct1 DBL ISAM
    DESCRIPTION "First Structure"
FIELD structfld1 TYPE ALPHA SIZE abc
    DESCRIPTION "A field"
FIELD structfld2 TEMPLATE MyTemplate
    DESCRIPTION "A field"

One of the templates references a non-existent template called "FakeTemplate" which is an error condition. The field "structfld1" is defined with with an invalid size, which is also an error condition. These errors are reported in Visual Studio differently, however, because of which phase the error occurred:

User-added image

10/4/2019 12:13 AM   1  
Ace Olszowka
@Marty Lewis

Thank you for the examples; what needs to happen to report errors of the first type (template.schema error)?

10/4/2019 1:33 PM   0  
Marty Lewis

@Ace,

For clarification, are you asking what it would take to to get file/line info for the resolution phase errors? Or are you asking how to make those kinds of errors occur?

If the former, we would need to evaluate how to store that information in a way that it would remain accessible through the whole parsing/resolution process. I can have some discussions about the feasibility and get back to you.

If the latter, anything that requires looking up another structure or field by identifier is going to be main source of resolution phase errors. Invalid symbols, incorrect types of symbols, etc.

10/7/2019 4:21 PM   0  
Ace Olszowka
Both

10/7/2019 6:29 PM   0  
Please log in to comment on this idea.