We use DSN-less connections to the vendor's files. If I query one field, not the whole table, this reduces to about 35 seconds. Complex queries take longer. Our record counter increments slowly by 's. Can anyone suggest: - directions I should be looking? THe client's IT support wish to migrate very soon, I am at a loss. Mike, I'll start by saying I'm a little baffled by the size of the trace files of your test program.
I would assume it would be a single SQL statement, or something close to that, but that is not obviously the case. How exactly are you reading the data? Can you post here the VFP code you're using? If I understood correctly, Mike's application connects to a Faircom server.
Is your VFP app running on the server or from a workstation? If it is the latter, I would try it on the server itself. If you can read the database in Excel, you might have found your workaround, read all the tables into Excel, then drop them into something easy to read in VFP like dbfs.
Aside from the trace log size, did you look inside it what differs? Even if you expect to understand nothing from it, comparing the content could easily shed a light on what Excel does differently, even when you programmed essentially the same query within VBA code and VFP code.
Anyway, to rule out it is VFP vs Excel you'd need to repeat the Excel using the driver, did you testrun the Excel version on the old server is that still available? Besides that, does the situation differ? Assumed you started with a fresh empty or even non existing tracefile and did the same things from the VFP side, what really differs? Server OS version? And as Griff already said, To exclude network issues, did you try to install the VFP program compiled at the server?
The problem can also be solved by creating well structured "Views" of the data if the source tables cannot be modified. Performance Considerations. Calling all SAS users! We now have even more FREE knowledge journeys. Learn more. Choose Your Journey. Need to connect to databases in SAS Viya? Sign In. Turn on suggestions. Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for. Search instead for. Did you mean:. All forum topics Previous Next. Loading data from ODBC cloud server extremely slow. In short, your software excercises some mechanics to package the query,send it and reposit the result — WinSQL does the same things, butclearlyWinSQL Is doing it better than yours is.
I am guessing that something is receiving the query onNZ…. Only a guess…Peter. This happened to me when i was running sql server linked server 3rd party tool to select from Netezza. Select result and execution was very fast in Netezza query history but result coming back to my linked server console was very very late. So Netezza asked me to put querytimeout option to 15 Seconds in the linked server setting.
So it got timed out after 15 seconds and rows were back on the console. I think Netezza should know about this issue.. Well, I am just a consultant here…and only been here 3 weeks……apparently upgrades of the nz 3.
You need to set up a separate test harness that uses your appdevenvironment. Iwould suggest you debug it right down to the software statement leveltosee where the actual problem is.
You might find that your local codeistrying to loadup a container, or finding other ways to water-board thedata, while thequery return itself is rapid. In short, your software excercises some mechanics to package thequery,send it and reposit the result — WinSQL does the same things,butclearlyWinSQL Is doing it better than yours is.
I am guessing thatsomething is receiving the query onNZ…. Sam, actually, I had not thought of that….. I was assuming it was waiting to start but when I look at the logs the LAST statement executes and then the app is waiting to finish……it looks as you say…. Both…it does not seem to matter……even the ODBC close and disconnects are waiting. Another thought in reading the thread. Netezza made significant catalog changes in the 4.
There is a patch for this, and this was resolved in the 4. It is 4. Good luck! Hi All, just to close this off…we put the question onto the netezza internal support site…. I will post if we get it working to let others know. Best RegardsPeter www.
So, the answer to this problem is to not set, or set to zero seconds this attribute. The connection still works fine and the client releases the connection as soon as it is completed.
0コメント