int conversion in for each stops the program without error

Is it possible that table.field contains a non-integer value somewhere?

That being said, this query is really bad. As soon as you put a function on the left hand side of the predicate the compiler cannot select an index properly and you'll get a whole table read.

This is only an easy example to show the problem. Yes in my field are some strings that are non-integer values, but i tryed it with non-int values like int("abc") and get no problems to reach the end.

i can fix my problem when i convert the int to a string and compare both, but i really want to know what the problem is with the int conversion.

Surely the solution lies in reworking the query to not need the integer conversion? Then you don't need an answer to this question, and your query /should/ perform a lot better as well.

_UserTableStat will give you the number of records the query retrieved before it stopped. So you will know a record to suspect.

Is the program crashing?  I.e., Do you get a procore/protrace file?

[quote user="James Palmer"]

Surely the solution lies in reworking the query to not need the integer conversion? Then you don't need an answer to this question, and your query /should/ perform a lot better as well.

[/quote]

But i am interested in an answer, maybe it is not the last time i see this problem, so it is better to know next time what really happend.

[quote user="Brian K. Maher"]

[/quote]Yes, but removing it didn't changed anything

[quote user="Brian K. Maher"]

[/quote]

Yes, but removing it didn't changed anything

[quote user="Brian K. Maher"]

Hi Dominik,

Are you using the -debugalert startup parameter?  If so, try removing it.

Brian

[/quote]

Yes, but removing it didn't changed anything

[quote user="George Potemkin"]

_UserTableStat will give you the number of records the query retrieved before it stopped. So you will know a record to suspect.

[/quote]

When i debug, the first record causes the problem

[quote user=" Laura Stern"]

Is the program crashing?  I.e., Do you get a procore/protrace file?

[/quote]

nope, i get no protrace file

has anybody tryed to reconstruct the problem ?

Which Progress version is this?

> the first record causes the problem

What is the value of table.field in the record?

Does 'FOR FIRST table WHERE INT(table.field) = 1916 NO-LOCK' show the same behavior?

Sports2000 DB

for each employee no-lock

 where int(employee.DeptCode) eq 500:

end.

That works fine in 11.6. I've not run it recently, but it's an example I've used as to why it's bad to use functions on the left.

And to be honest, if you find the same situation again, you should fix the query again. It'll work ok for small tables, but trust me, it will be horrible for any table of significant size.

it is progress 11.4

i checked some records, every record with non int conform input couses the problem like "abc" or something.

But when i put int("abc") into the query without the field it is no problem.

For first shows the same behavior.

abldojo.services.progress.com:443/

That gives a runtime error.

Are you handling errors within your actual code that is suppressing it going to screen?

Using a temp-table hides the issue (and directly throws the run time error).

Using a shared-memory connection (which abldojo uses) also hides the issue (I think )

Using a networked connection the issue is easily reproducible (I'm using 11.7.1 x64 on Windows

I guess the reason is: INTEGER(table.field) is resolved on a server's side. And remote client server does write the error 76 (Invalid character in numeric input) to a db log.

With both connection types (shared-memory and network) query generates the trappable STOP condition.

[quote user="Stefan Drissen"]

Using a temp-table hides the issue (and directly throws the run time error).

Using a shared-memory connection (which abldojo uses) also hides the issue (I think )

Using a networked connection the issue is easily reproducible (I'm using 11.7.1 x64 on Windows

[/quote]

Yes, i tryed the tt example with my local 11.4 version and get the error with the connected DB i get nothing.

[quote user="George Potemkin"]

I guess the reason is: INTEGER(table.field) is resolved on a server's side. And remote client server does write the error 76 (Invalid character in numeric input) to a db log.

With both connection types (shared-memory and network) query generates the trappable STOP condition.

[/quote]

I started my local server with the web based open edge management concole.

[2017/09/21@08:48:36.128+0200] P-10344      T-5788  I SRV     1: (76)    ** Ungültiges Zeichen in num. Eingabe s.

My logFile gives me the same error as i saw with the temp table test.