Please change "FieldByName" to "FindField" for robust reason

[Liang]

Hello

As you may see from my posts, I am not developing a software handling with Oracle database, it gives user's ability to use difference scripts to data-mining the raw data, and prevent them vividly to final user.

User can uses TeeChart build-in ChartEditor, at run-time, try different fields in script result dataset for different series And user can save the above datasource field binding, reload at a later time.

Then I found some AV errors, for no-existing field in following cases:
1. load the series setting while data is not actived
2. or user is changing/trying a new scripts without changing the series setting at the same time.

So, from a user-friendly and robust code point of view, I modified following source code, and would like to contribute to you:

DBChart.pas

Code: Select all

      Function GetAField(Const FieldName:String):TField;
      begin
        if FieldName='' then result:=nil
                        else result:=tmp.FindField(FieldName);// changed from 
                        //FieldByName(FieldName)

[Narcís]

Hi Liang,

FieldByName just calls FindField and throws and exception if it returns nil. This exception is necessary to let programmers and users why a series is not being populated.

[Liang]

Hello

You are right that in case of field not exist, FieldByName will raise an exception.

The problem is that if the user saves the chart setting, who has a series linked to a dataset, and next time if he loads the setting, such non-existing fields will raise an exception, and user may intercepts that TeeChart itself has some bug at loading setting, which causes a bad use-feeling.

By changing "FieldByName" into "FindField" will prevent such mis-leading exceptions, while TeeChart source code already have NULL value checking for the result returned.

So my title is for "robust" reason.

[Narcís]

Hi Liang,

I may not understand your point here but when exporting a TeeChart to a native template file (*.tee) or a memory stream, datasources are not exported. You can choose to export series data but datasources information won't be exported. On of the reasons is because you may not load the *.tee file in the same machine where it was created and therefore necessary database connections may not exist there.

If that's not related to what you meant please give us more detailed information about the issue.

Thanks in advance.

[Liang]

Hello

Maybe I am not expressing my case clearly.

Now I am working on a software, that user can use it to data-mining a Oracle database.
So user try different SQL, result returned, and then user can display result to a Chart.

Now user first uses:

"select a,b from table1 where time=today"

and then show the result of a and b in a Chart with field linked to "a" and "b".
then user changed the query into

"select a,b from table1 where time=yesterday"

TChart will automatically have the series updated. Perfect!

But the user now changing his mind to a new query

"select c,d from table2"

when this query performs, TChart will raise an AV for field "a" and "b" not found whenever dataset updates until user manually open the chart-editor, click, click and click to find the right place to delete the fieldname binding, which is very user-unfriendly.

And since data-mining is quite time-consuming, so if user save the chart setting before she leaves office, next day, she loads the settings at the same machine connected to the same Oracle, such AV will also happen since DataSet is not active yet.

So I trace the source, and found we may change this "FieldByName" into "FindField", then we can avoid such AV. Meanwhile, all the TeeChart caller to this function all have safety protection already against returning a NULL value, so such modification will not have bad impact to TeeChart's perforamance.

So my title is for "robust reason". Of course current plan is not an bug, as you have said, but it make user unhappy and angry.

[Narcís]

Hello Liang,

As I told you before, we think it's necessary using FieldByName and leaving to the programmer the option to catch the exception and act accordingly. Of course, you are free to customize TeeChart sources at your end to fit your specific requirements.

[Liang]

It's fine.

Thanks for your kind support