Have BAQ Calculated field check for problems with names

Feature Requests and Suggestions
1

When making calculated fields, you can name them whatever you want. However, if you use names that are already in the SQL it can cause problems. It would be helpful if the system could check the name of the new field and see if there are any problems with it. Currently, it gives the syntax error, but it can be really hard to figure out what it’s trying to say. It’s only recently that I realized that those names can give so much trouble. In the past, I’ve added fields to a previously working BAQ and all of the sudden it doesn’t work. I couldn’t figure out why the new field was problematic. Looking back now, it was probably the name of the calculated field, but I couldn’t figure that out, because the error was too generic.

2

That’s weird because at least in 10.3 the fields are called Calculated_ so that should “never” interfere… I have seen what you mention though, I’m confused as to why

1 Like
3

Same in 10.1.500 - @Banderson do you actually have SQL Fields named Calculated_Something?

4

I don’t have a specific example right now, I just was randomly thinking about it and the thought popped into my head that it should be possible to check for the problem programmatically and give a more intelligent warning.

I think the problem shows up when you name the field something that is is the calculated field. For example if you are using the RANK windowing functions, and you call your field rank, it pukes. But change calculation to use ROW_NUMBER and the syntax issue goes away. So a lot of times it can sneak up on you and really get you confused.

It’s human nature to call the field what it is actually doing, so it’s a common problem to create conficts. But like @josecgomez said, the system calls it Calculated_yourfield so it shouldn’t cause a problem, but it still does sometimes.

5

Here is an example that a customer attempted in a query that then caused issues:

They created a Calculated field called DateDiff. I don’t remember what the expression was for the calculated field, but as soon as we called it something different (and not a SQL reserved word), the query would execute.

Unfortunately, I do not remember what version this was in, but it looks like @josecgomez is correct in that the 10.2.300 version, this will execute without error.

Thanks,

1 Like