Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ORA-01489: result of string concatenation is too long #34

Closed
PhilippSalvisberg opened this issue Jul 13, 2021 · 2 comments · Fixed by #39
Closed

ORA-01489: result of string concatenation is too long #34

PhilippSalvisberg opened this issue Jul 13, 2021 · 2 comments · Fixed by #39
Assignees
Labels
Milestone

Comments

@PhilippSalvisberg
Copy link
Owner

For some objects following error occurs on the Identifiers, Table Usages and Column Usages tab:

2021-07-13_16-34-25

The obvious reason is that the sys_connect_by_path function produces a result with more than 4000 bytes. This can happen only with more or less 130 levels (assuming a max of 30 characters per name). In a customer's case there are more than 700 levels. Most levels were artificial. Produced by the fix of inconsistent PL/Scope data (missing levels). In such a case the node was connected to the last previous consistent node. In case of a series of calls to a unit which is not compiled with PL/Scope this leads to a lot of nested levels where no nesting would be expected.

@PhilippSalvisberg
Copy link
Owner Author

Two actions:

  1. Try to find another solution to fix inconsistencies without producing additional levels
  2. Try to avoid an overflow in sys_connect_by_path

@PhilippSalvisberg
Copy link
Owner Author

Additional levels have to be avoided from also from a performance perspective, since every level is processed separately (full scans).

rvo-cs added a commit to rvo-cs/plscope-utils that referenced this issue Jun 28, 2022
This fixes issue PhilippSalvisberg#34:

    ORA-01489: result of string concatenation is too long

by ensuring that the length of name_path remains <= 4000 bytes,
replacing as many levels as necessary by .../ starting from
level 4, so the first 3 levels are always kept, and the tailmost
levels should be preserved too.
@PhilippSalvisberg PhilippSalvisberg added this to the v1.0.0 milestone Jul 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant