Quantcast
Channel: Toad Data Point Forum - Recent Threads
Viewing all 2544 articles
Browse latest View live

RE: I have an automated job, the query pulls for instance 5 rows, but only exports 3 of them. Any idea? I'm using TDP 4.0

$
0
0

That is a weird  problem!  Check the connection for your automation job and if you use a different connection with in the job step than your manuall connection.  You can also run a query step just before your export and put the row count into a variable, then put in a step to log the value in the row count variable to the job log.  Then you can make sure you are actually getting all the rows you are trying to export by viewing the job log after it runs.  It is possible to use a different connection for an export than what the default connection for the job has (specially if you are using and export module .txp file), so check.

Good luck,


RE: I have an automated job, the query pulls for instance 5 rows, but only exports 3 of them. Any idea? I'm using TDP 4.0

$
0
0

this sounds like a support case i am working on. But i don't have any files to look at. please provide all automation files, dependent files, and automation logging file so i can look into this. 

RE: TDP Giving Up on Query Connections with No Error in Automation

$
0
0

Is is possible that the hang is on the database side? The dmp file shows that it never returned from a get from the server. 

RE: TDP Giving Up on Query Connections with No Error in Automation

$
0
0

I don't believe so Debbie.  The reason for this is when you run the same query using the editor and not the automation, although it may take a bit to return results, it does complete regardless how long it takes.  Also, using other software such as Access or another old software we use, it does not just hang and end the connection.  I do agree it never gets data from the server, but I believe its because the connection is lost somehow and then just hung on the TDP automation side after that. 

Thanks

Chad

TDP Giving Up on Query Connections with No Error in Automation

$
0
0

I hope I can explain this well.

This is a problem that we've had for some time, but I was really working to ensure it wasn't an issue on my end before I submitted this to TDP.  I do believe it may be on the TDP product end.  Essentially we use TDP 4.0, but I've seen the problem as well on earlier versions.  We have our queries that connect using an I-Series ODBC connection to an AS400 using DB2 SQL.  All of our queries use this.  With that being said, I've noticed quite frequently that long running queries (those that take possibly an hour or more to run) have issues specifically when running in automation that are essentially giving up the connection to the query and continuing to run on the machine.  Therefore, when I come in in the morning I notice that the little toad icon is still up and the automation task is still running and I have to forcibly end the task and then attempt to rerun. (It will work usually when rerunning and this issue isn't present every time the query runs, just on and off, most notably when CPU is higher and query times are running even longer than normal)  I have the ability to check the query running on the AS400 and when I do this on these queries in automation that give up and essentially keep running, I notice that the query is no longer running on the AS400.  Therefore, I'm suspecting that somehow the query either times out or is killed some how on the TDP automation end, but throws no errors back.  The reason I believe this, is I also have the ability to terminate connections to queries on our AS400 which means that I can stop a query on the AS400 side.  If this was the case, or connections get lost, I always throw back an error on the automation that the connection has been lost, which is great and tells me that it will error for connections lost on the AS400 end.  This is why I assume its something with the TDP product.  I'd like to see if the wonderful TDP support folks have seen this issue before and if not, what information I may be able to provide to help this issue to be researched.  Also, I'd love to hear if anyone else has experienced anything similar. 

Hope to hear from you soon. 

Chad

RE: I have an automated job, the query pulls for instance 5 rows, but only exports 3 of them. Any idea? I'm using TDP 4.0

$
0
0

Could you please clarify what activities do you use in the automation script for exporting data? Is it Select to file activity? Or Export wizard activity? (Just to narrow down the problem)

Can you please check what is the setting of "Start export at: "? (there should be the position to a cell in excel like "A" "1"). Could you please verify that this is correct? Maybe you use some headers in the excel file. Not saying it's the root cause but i remember once i had problem with this setting.

What is the row count difference approx.? In thousands?

When this case happens Is the row count difference always different (random-like) comparing to previous occurrence?

We are now on Twitter!!! Contact a Technical Support expert today.

$
0
0

Do you have a quick support question and short of time? Contact us Via Twitter  @QuestExpertsand we will take care of you. #Jointheinnovation #WeareQuest

RE: Are you using Toad Data Point with Netezza?

$
0
0

Hi Julie,

We are using Toad Data Point for Netezza.

Thanks,
Jeremiah


Netezza connecting but not to all tables

$
0
0

Hi Toad,

My computer crashed recently. I had to reinstall Toad and set up the connections again.

Prior to the crash, I had been able to see and query from all the tables in our Netezza database in Toad. Now, while I can connect to Netezza now with some delay, there are a few key tables that I can no longer view nor query from as I get an error message saying that no such table exists.

I know that this is a Toad problem as I can access those tables just fine from Tableau 10. Please advise.

Thanks,
Jere

RE: Are you using Toad Data Point with Netezza?

$
0
0

Although Toad Data Point 4.0 seems to be much slower on Netezza connections than previous versions

Are you using Toad Data Point with Netezza?

$
0
0

Hi everyone,

I am doing some research into our connectivity with Netezza.  If you are using Toad Data Point with Netezza and can spare a few minutes to write me an email providing feedback on your experiences?   Or if you would prefer and you and have the time, I can schedule a quick call and get your feedback on the phone.   Just email me at julie.hyman@software.dell.com.  I can even send you a free Toad T-shirt Smile

Thanks very much for your help!  

Julie Hyman

Sr. Product Manager

Dell  |  Quest Software

RE: Netezza connecting but not to all tables

$
0
0

Hi,

You could check your ODBC driver settings. I had similar issue with DB2 shemas. Changing library view to All libraries on tab Catalog solved my problem 

RE: Netezza connecting but not to all tables

$
0
0

Are you doing that through Toad or your Data Source Administrator?? If I can connect to the table through another medium why would it not show up in Toad?

RE: Netezza connecting but not to all tables

$
0
0

I've done it through Data Source Administrator. After that Toad started showing all existing schemas and tables. All other tools displayed everything with default driver settings, so Toad seems to be special in this question:)

However I'm not sure completely our issues are the same, so my advice may not work out. But hope it works

RE: Are you using Toad Data Point with Netezza?

$
0
0

We found that some ODBC connections did not support multi-threading so we added a feature to disable multi-threading. In TDP 4.0 multi-threading is turned off by default. Turn this back on and see if that gives you better performance. The option is on the Advanced tab of the connection. 


RE: Are you using Toad Data Point with Netezza?

$
0
0

Debbie,

That is a little faster.

Thanks,
Jeremiah

RE: Netezza connecting but not to all tables

$
0
0

Are these system tables that are not displayed? There is an option for that in the DSN configuration

RE: Buggy behavior: TDP 3.8 overwriting Vertica SEARCH_PATH with "default schema"

$
0
0

Hi Filip - sorry for delayed reply.  Glad to see this is getting proper attention.  I would recommend, for consideration, simply offering an option to disable this feature (if not disabling by default for Vertica connections).  So far as I can tell, the main behavior is that, when using the editor, every SQL statement is pre-empted with command to set the CURRENT_SCHEMA (in Vertica parlance, SEARCH_PATH) to match whatever is in the dropdown.  If that behavior were disabled (for Vertica, it really is needless - each user can configure/customize their own SEARCH_PATH for their database account and/or for a given ODBC connection).  SEARCH_PATH is really quite nice; it eliminates most all of the scenarios for which a given user would need to toggle their schema in other database products.

Buggy behavior: TDP 3.8 overwriting Vertica SEARCH_PATH with "default schema"

$
0
0

Where most other databases use CURRENT_SCHEMA, HP Vertica uses a SEARCH_PATH.  SEARCH_PATH allows users to list multiple schemas for which an object should be searched during a particular session.

So if my current session's SEARCH_PATH is:

Schema1, Schema2, public

If I run SQL "SELECT * FROM FOO;"  over that session, Vertica will attmpt to resolve the schema of FOO by looking for Schema1.FOO, then Schema2.FOO, and finally, public.FOO.

Toad Data Point has 3 bugs in how it handles Vertica's SEARCH_PATH feature.

Bug#1 (minor): Connecting Toad Data Point to a Vertica Database requires an ODBC connection.  One of the properties of a Toad Data Point ODBC connection is "Database".  For Vertica ODBC connections, this is an "invalid option" bug.  For Vertica connections, the choice of database is built into ODBC source definition (the database is part of the ODBC URL).  This option should either be invisible, or as a hard-coded/non-editable field that just lists echos the database portion of the Vertica connection URL. 

Bug #2 (minor): In addition to being unnecessary, this "Database" field is also mislabeled.  As evidenced by the dropdown list after clicking the [...] button, the field is actually referring to "the default schema that is set after connection is established".  This bug (the label says Database when it means Default Schema) can be verified directly: when configuring a new Vertica ODBC connection in Toad Data Point, when I click the "..."  next to "Database", the drop-down of values is actually all the schemata in the Vertica database (not the "list" of databases which, as noted in Bug 1, can only be database string in the URL).

Bug #3 (major) The real problem is how Toad handles the "default schema" for ODBC-Vertica connections.  Say I choose "Schema2" for the the "Database" option of a Vertica connection.  Based on this setting, when I open a new connection, Toad sends the following SQL string over ODBC: "SET SEARCH_PATH=Schema2".  

What makes Bug#3 such a nasty bug is that

1) This command gets run (automatically) after all other connection settings are applied.  So if my Vertica user account has default SEARCH_PATH of "Schema1, Schema2, Schema3, public", that default is overwritten by Toad Data Point to just  "Schema2". Even if I make my desired SEARCH_PATH using the ODBC Connection String, this bug overwrites that value.  

In other words, if I put "ConnSettings=SET SEARCH_PATH TO Shema1, Schema2, Schema3, public" in Connection String, and set that same SEARCH_PATH for my user account, after I connect to Vertica, and run SHOW SEARCH_PATH;, I will see the search-path is just "Schema2".  The behavior can also be observed after connection is established.  If the "default schema" (hover-text = "Select the schema/instance to associate with the statement") is changed from Schema2 to Schema3, behind the scenens the command "SET SEARCH_PATH=Schema3" is sent.

2) This behavior cannot be disabled.  This is my main beef.  The behavior pretty much completely prevents using SEARCH_PATH functionality in Toad Data Point; which effectively eliminates any ability to use Vertica's SEARCH_PATH feature - a sufficiently large obstacle to entice me to find an alternate IDE for Vertica analysis (and recommend the same to colleagues).

RE: I have an automated job, the query pulls for instance 5 rows, but only exports 3 of them. Any idea? I'm using TDP 4.0

$
0
0

It's to put the results of the query into an excel file.  It's one huge file that's broken down into several xls files.  It's an Export, not a select to file.  In the Output file there are several queries that create several xls document; and in the automation file there are several run query commands nested with the output file.  So it tells it to run the query, then for client code 1 make this xls and client code 2 make another one.  Then it runs another query and puts the data on tab 2 of client file 1, etc.  I can't make it into several automations because depending on how many providers the initial code pulls, determines on how long the query takes to run, and the first query has to completely finish before the next step starts because the second set is dependent on the first step.  Also, the first step has to completely run because in some cases the second step drops a table that the first step used and uses the same table name, because I have a limited amount of space in my schema, I reuse the table names.

Viewing all 2544 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>