We're experiencing at random, but not often, one of our tables (Child Table Window) being unable to be populated. Is there a known issue with this type when it is unable to be filled?
The problem seems to be related to the client (Team Developer 7), since we've managed to get the actual SQL statement unable to fill the table and the SQL statement does return values when run from the Oracle database.
Again, this is a random behavior issue and it does not often occur, but still of importance..!
- Founder/Site Admin
- Posts: 468
- Joined: 24 Feb 2017, 09:12
- Location: Gouda, The Netherlands
As you said it is random, but can you reproduce yourself on occasion?
Is it always on the same SQL query, with different resultsets or is the resultset in all cases the same?
When you are able to reproduce, you could try using SQL Monitor to see how the query is being processed by the application
We're using SalTblPopulate.
It does not happen often and it is difficult to reproduce. We're currently unable to do that.
It's mostly the same queries run. We've seen a basic query used from our application return no records in the client, but in the database.
We've managed to fetch the SQL statement with Toad's SQL Monitor. The query does return records when run directly from the database and parameters, but sometimes returns nothing from the SQLWindows client application. Reopening the client solves the issue, but we're looking for a way to figure out why this happens at random.
Are there any known errors with the Child Table Class?
I'd recommend setting Max Rows = 100,000 or something very large. TD doesn't pre-allocate that amount of memory for 100K rows, only that it will allocate as necessary up to that value.Max Rows in Memory is set to 6000
Code: Select all
FR asked about the size of the result size
Very important: What is the method, the TBL_Fill constant that you pass as the last parameter?We're using SalTblPopulate
Code: Select all
we've managed to fetch the SQL statement with Toad's SQL Monitor
Things to try:
Breakpoints: Have you set a breakpoint (BP) on the beginning of your code that contains the CTD's SQL and single-step?
This is the first thing I do: single-step, check that the Prepare works -- I copy/paste the statement so I can test in SQLTalk if necessary (see below), and so on.
Max Rows: change to '0' - this = Dynamic.
If you call SalTblSetRange in the code, then pass 0, TBL_MaxRow as the range
SalTblPopulate call: I'd try passing TBL_FillNormal. That fills the CTW's visible range with a row or rows only.
Result set size: Change the query to return 1 row, say, of a very small number of rows, just to be sure that something is getting returned.
Transaction model: Could this be a database locking issue? If any row(s) is/are part of another user's result set, then, depending on the model that is definec, the fetch I believeis going to pause until any locked rows are freed. Are you waiting when your CTD doesn't populate right away? SQLBase, for example, has a 300 second as I recall (5 min.) wait for any locks to get released before it throws a deadlock error.
Does your code make sure to Set bBoolean = SQLxxx or catch a FALSE return from any/all SQL/SAL functions that return a FALSE if the statement fails? Coding like this:
is, to me, bad coding since you are ignoring any error return. And if SqlConnect() fails, then SqlPrepare etc. are sure to fail as well.
Generally, SAM_SqlError will get sent to your code on a SQL error and if you don't trap that msg. in the Appl. Actions section then TD will display a default error msg, but there might be an issue with the code where there's no SQL error. Instead, I'd write something like:
Code: Select all
If NOT SqlConnect() ... error so display msg. box and ... Return FALSE ! this halts code processing; it doesn't terminate the app. ... etc.
1) use the Breakpoint feature to narrow down where a failure is occurring. Then investigate why.
2) write a small test appl. that can reproduce the problem.
3) copy/paste a test version of the form/dlg. box where the CTD is to another test appl, do what you need to to make it self-contained and test that way.
Also, as I wrote, try to narrow down the problem (I call it the 'edges') to help you find what the problem might be. SQL problem returning 0 rows, locked rows in the DB, or...?
Palm Springs, California
TD info. & samples: http://www.jeffluther.net/TD/
Who is online
Users browsing this forum: Ccbot [Crawler] and 0 guests