Skip to main content
To homepage To homepage
SUBMITTED

Allow more freedom in the Query tool

Related products:TimeXtender Data Integration
  • December 8, 2023
  • 4 replies
  • 33 views
P
Contributor
Forum|alt.badge.img+2

Hi,

When using the query tool, TimeXtender does not allow you to use multiple fields with the same name:

The table used for reference
Adding another “Country” field to trigger the error

This was not the case in version 20 and previous. It is a bit annoying because we mostly use the query tool to do ad hoc queries for data investigation, transformation testing etc. 

Doing this quickly does of course not produce the prettiest queries but that does not matter because they are not intended to be saved.

Having this extra limitation set by TimeXtender provides no clear benefit and only slows down aforementioned process.

The current work around is to use SSMS, but it is unfortunate to have to jump between softwares.

 

Appreciated if anyone had a look at this.

Best,

Pontus Berglund

4 replies

rory.smith
TimeXtender Xpert
Forum|alt.badge.img+8
  • rory.smith
  • TimeXtender Xpert
  • December 8, 2023

Hi,

using the same name multiple times is valid (in SSMS / SQL Server) but I am not really sure what the value is. If you are using it to have a column repeated for some kind of crosscheck in a broad table, I would use multiple statements. This used to be possible in v20, but no longer seems to work.

As a work-around you should be able to alias the field [Country] AS [Country two] to prevent the error.

P
Contributor
Forum|alt.badge.img+2

Hi @rory.smith,

My point is that there is no value added with this extra limitation set by TimeXtender, it makes the user experience worse because it forces the user to spend extra time on unnecessary coding. 

When doing quick ad hoc analysis of a table, it is nice to be able to copy and paste stuff and write code fast without having to worry about having it look nice.

In my opinion this is similar to if TX suddenly demanded the use of brackets on column names in the query tool or if the query tool became case sensitive. I just don’t see the reason for it.

rory.smith
TimeXtender Xpert
Forum|alt.badge.img+8
  • rory.smith
  • TimeXtender Xpert
  • December 8, 2023

Hi @pontus.berglund ,

I get your point :-)

There is however the issue that TimeXtender needs to support other engines than SQL Server (and there are already differences between IaaS, PaaS and Synapse SQL) like Amazon RDS and Snowflake. To have a generic solution for all will require some kind of “lowest common denominator” compromises I suspect. 

I agree that this “seems” to be arbitrary, if there is no technical reason then it should be possible.

 

Note that Snowflake is (by default for a session) case-sensitive, so I would get used to being precise. For SQL it depends on the collation you are using. I have customers that do use case sensitive collations and this always results in fun with Product and product not being the same thing...

P
Contributor
Forum|alt.badge.img+2

@rory.smith Yeah, I totally get that there could be a technical reason for this, and if that’s the case I am fine with it :)

But as you said, Snowflake is case sensitive which one will notice when using QT etc. but in the current version, case sensitivity is not enforced across the board (really hope it wont become).

If technically possible I think it would be great if TimeXtender did not try to aim for a lowest common denominator approach for custom coding, but rather let errors be thrown by each respective technical platform. By custom coding, I am thinking of e.g. the query tool, custom views/table inserts, snippets etc. Even if they did try, it would not be bulletproof since SQL and Snowflake has different functions etc.

Of course they are going to aim for platform independency for standard TX functionality, which is one of the great things about TX.

It would be interesting to get more insight into this.

    Terms and ConditionsAccessibility statement