Can we run a simple query using source endpoint

[adbdkb]

I am just starting to explore Qlik Replicate.  My first task is replicate a DB2 table to a Kafka topic.  So, I am trying to set-up the source and target endpoints.  

I do not know the DB2 database - it belongs to a different team.  So, one of things I would like to do is run simple SQL SELECT queries on different tables in the schema I am going to work on to understand the database a little.

Is there a way to run queries on a connection?  If so, how can I do it?

Thanks

[Michael_Litz · Accepted solution]

Hi,

I am sorry to say there is no way to run SQL queries against the endpoints defined in replicate. You will need to use a SQL tool that is outside of replicate.

Thanks
Michael

[adbdkb]

Hmm, ok.  I don't have access to any other tool and also credentials.  The person with credentials entered them for me when creating the endpoint.  So, even if I got hold of some other tool, I still couldn't use it easily

[shashi_holla]

If you are setting up source endpoint then I assume you should have the credentials (username/password) for that connection. Usually source endpoint is a read only access and you should be able to connect to Database directly using that access. If you are not sure of the query syntax then create a simple task with one or two tables, enable verbose logging and in the logs you should see the list of queries that Replicate has created which can be used to query the source database. Hope this helps.

[Michael_Litz]

You make an interesting point. Please do follow this link and add a feature request for replicate.

To submit Feature Requests going forward please use our Qlik Community "Product Insight and Ideas" forum as these requests will no longer be handled as technical support cases. As a Qlik Community member, you can actively engage with our Product Management team, vote on a product idea coming for other Qlik customers, submit your own ideas and get feedback from other members.

To get started please see our article: "Getting Started with Ideas": https://community.qlik.com/t5/Qlik-Product-Insight-Blog/Getting-Started-with-Ideas/ba-p/1684011

You will be required to have a Qlik ID to logon to the Community which is not the same as your support portal logon. If you have previously registered for a Qlik ID such as one you  use to access the downloads site, you can use the same to logon for the Community. First time accessing Community with a Qlik idea will prompt for a username alias to be used when posting to the Community.  This alias is not a logon but for display purposes when posting. If you do not have a Qlik ID for logon, you can register at the logon screen. The Ideas blog post will provide information on how to use the Ideas board and how to access it.

If you have any issues registering or logging on to the Community, please submit a new case with the issue you are having so we can direct the case to our Customer Service team for assistance.  Please let us know if there is anything else we can do for you at this point as this is no longer the place to submit feature requests.

Thank you,
Michael Litz
Customer Support Engineer

[adbdkb]

I understood what you said about using some other tool.  What I am saying is that I did a screen share with the person who has the credentials and she put in the password.  So,  I do not have the credentials to create the connection without the credentials and I will have to explain to them why I need to do it in other tool.  

[Heinvandenheuvel]

I don't recognize this as a valid feature request.

I fact I would think it would be a total security disservice if the endpoint could be used for random queries.

>> What I am saying is that I did a screen share with the person who has the credentials and she put in the password.

Perfect. That's the correct way to manage security.

>>  will have to explain to them why I need to do it in other tool.  

indeed. And you probably have no valid business reason, merely curiosity.

>>  I would like to do is run simple SQL SELECT queries on different tables in the schema I am going to work on to understand the database a little.

Replicate is just a tool in the middle. The business decides what is needed on the target, and what is available on the source. The Replicate team just makes it happen. Unless so appointed by the business your task is not to wonder why, no matter how tempting.

I understand, and share the desire, to fully understand the source but that's not a good enough business reason. You may well be able to help the business  by understanding the source better but it is not required to create a replication task, and possibly not desired by the business. Their loss, but they are in the their right.

Replicate will show the schema/tables/columns you are allowed to see in the GUI. If those create challenges, issues, then by all means pounce back at the folks barring you from general access telling them they _must_ help you because you are not given the access to help them.

Note, You can satisfy your curiosity to a degree by enabling SOURCE_CAPTURE, and SOURCE_UNLOAD logging to TRACE or VERBOSE to see the queries being issued with result in the log and/or UI.

Good luck!

Hein

[adbdkb]

If I am asked to replicate a table, how is it not a valid reason to try to understand the same data?   Also,  when one of my teammates was working on replicating from sql server, there was one data type in sql server ( don't remember exactly which one, ) that the replicate tool didn't handle, but it took a while for them to identify the actual issue.   Ultimately,  they weren't able to use the replicate tool and had to use some other mechanism

And it may not even be that they don't want us to know the data, but they don't understand the tool and may feel it a hassle to set-up the credentials in various different tools.  

And there could be various valid reasons to know the data - if you have to transform any columns, combine columns, it is always beneficial to know the data, rather than blindly doing it.  Because knowing the data can drive how you best deliver what the business wants / needs.   Even the size of the table, may play a role when initially defining and testing the task.  

So, I wouldn't consider knowing the data as mere curiosity.  

[PGN]

Toad is a pretty widely recognized tool to query various platforms and it works for DB2.  As far as seeing/analyzing the data, I guess it's really up to your company structure and your role and the people who manage data governance to determine that.  If you're working with Replicate, I would think that would be part of you job responsibilities, just for troubleshooting issues alone. 

[adbdkb]

Agreed, that data analysis / access part depends on various gates around security that have been implemented.  My only point above was - if one is working on replicate tool and wants to know the data they are working with, it is not just a curiosity.  As you said, it would be part of the responsibility just for trouble shooting the tasks being defined.  

As far as being able to "see" the data, from security perspective, you can define a task where you can have the target endpoint as a file, where you can see the data.   And yes there are many tools like, Toad / SuirrelSQL that can be used.  The only point I was making there was, to the business person, if they don't know the differences / capabilities of different tools, they can consider it to be a hassle to keep on entering the password - which they also have to retrieve from a vault.