I recently migrated from TDP Pro 3.8 to TDP Pro 4.2 64-bit.
I find that when I have query results from a Hive query, and I click the Profiling tab, I see the summary data, but when I click the “Full Profiling” link on top-right, nothing happens.
Full profiling works OK in 4.2 when I had results from an Oracle query, however.
This worked perfectly fine in 3.8, for Hive queries (32-bit driver), I did it a lot. But now 4.2, Hive result sets are not sending to full profiling. ?? any advice?
Best I can determine, I get this exception, when I click the link:
New exception: 4/17/2018 7:17:42 PM
Quest.Toad.Exceptions.IgnoredException: Could not resolve connection for TRL: odbc://1A+Hive+IT+KERB+BW3/
Stack trace:
at Quest.Toad.Trl.TrlScheme.ResolveConnection(String trl, String xml, Boolean allowOpen, Boolean visible)
at Quest.Toad.Profiling.ToadProfileSource.GetConnection()
at Quest.Toad.Profiling.FullProfileOptionForm.set_ProfileSource(ToadProfileSource value)
at Quest.Toad.Profiling.FullProfileOptionForm.ProfileData(FastTable table, ToadDataAdapter adapter)
at Quest.Toad.Profiling.ProfileOverviewControl.fullProfileItem_ItemClick(Object sender, ItemClickEventArgs e)
at DevExpress.XtraBars.BarItem.OnClick(BarItemLink link)
at DevExpress.XtraBars.BarButtonItem.OnClick(BarItemLink link)
at DevExpress.XtraBars.BarItemLink.OnLinkClick()
at DevExpress.XtraBars.BarButtonItemLink.OnLinkAction(BarLinkAction action, Object actionArgs)
at DevExpress.XtraBars.ViewInfo.BarSelectionInfo.UnPressLink(BarItemLink link)
at DevExpress.XtraBars.Controls.CustomLinksControl.OnMouseUp(MouseEventArgs e)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at DevExpress.XtraBars.Controls.DockedBarControl.WndProc(Message& msg)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
We reproduced the issue and created QAT-12819 to track it.
As a temporary workaround open data directory (Help|About and press Application Data Directory link), create a copy of KnowException.xml file and empty the original file.
Okay, we got the new driver and connection working. But we have tried everything we can and cannot reproduce. If you change the order of our connections or the Names of the connections does this get past the error? It seems some kind of lookup error.
I moved a connection, still same error.
I renamed the connection (just the Toad name) and still same error.
To be clear, the problem occurs ONLY when the connection is to a Kerberos Hive server.
I have another Hive that is NOT Kerberos, and profiling works ok there. CORRECTION: I Just tried this again after I posted this reply, and now the profiling isn’t working for the non-Kerberos Hive either. Very weird.
Does the profiling need to connect to the target again, even when it has all the data retrieved already?
That’s what puzzles me, why it needs to re-resolve the name.
Could it be that some of the Kerberos parameters are confusing the parser somehow? Just guessing.
I could try adding a completely new connection again - including a new ODBC conn, then point to it from a new Toad conn, and see what happens. UPDATE: Created all fresh, including a new connections.xml file, but still get same exception.
Can you confirm you are testing against Kerberos Hive?
There are a zillion parms for Kerberos and ODBC, so maybe we have to dig into those variants as well.
I could reproduce your issue with TDP 4.2 and 4.3 no matter kerberos or not, as long as it's ODBC way.
I did thoroughly testing on HIVE against various TDP versions, all of them work good with 5.0, could you try latest 5.0 beta? download from here:
Haven’t checked in on this issue in a while.
My company is not supportive of me doing beta, so i have to wait for 5.0.
Is there any ETA on when 5.0 will be released?
I saw in another post there was a Feb1 target, but that has come and gone, and i did not see any announcements about 5.0 GA.
Please advise, thx.
New ETA is Mid April. If you email me directly I can get you a preview copy. debbie.peabody@quest.com But when I look at this issue QAT-12819, we never were able to reproduce so we did not make a change.
Hmm. that’s not what Cindy.Sang said above in earlier comment in this thread.
Looked like she reproduced it and confirmed the behavior in 4.2, 4.3, and 5.0.
can you find out for real?
It is a huge and slow process for me to get new versions of sfw (not allowed to download sfw from the outside, without jumping through many many hoops)
we are hoping to get approval for new version of TDP, but if that bug still exists, i’d like to know. It may affect our plans for upgrades.
Sorry to make you confused, I could reproduce this issue with TDP 4.2 and 4.3, but TDP 5.0 somehow works(it might be gone with control update), that’s why Debbie comment we did not make a code change, would you like to get a preview copy to take a try?