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
More information about dependencies is needed [CORE770] #1152
Comments
Commented by: Alice F. Bird (firebirds) Date: 2006-01-17 14:06 Claudio, could you please post an update what's still not |
Modified by: @pcisarissuetype: New Feature [ 2 ] => Improvement [ 4 ] assignee: Dmitry Yemanov [ dimitr ] SF_ID: 807869 => |
Modified by: Alice F. Bird (firebirds)description: SFID: 807869# I've logged this issue as a request for enhancement and Following with my example script described in: IB keeps track of table2table dependencies through PKs What's missing, among others dependencies: C. ---------------------- Procedures using generators and UDFs are tracked now in => SFID: 807869# I've logged this issue as a request for enhancement and Following with my example script described in: IB keeps track of table2table dependencies through PKs What's missing, among others dependencies: C. ---------------------- Procedures using generators and UDFs are tracked now in |
Modified by: @pcisarassignee: Dmitry Yemanov [ dimitr ] => |
Modified by: @dyemanovassignee: Claudio Valderrama C. [ robocop ] |
Commented by: Claudio Valderrama C. (robocop) 1.- Domain depends on table. Solved. See CORE282. SQL> create database 'depends.fdb'; 2.- Domain depends on procedure. Solved. See here: 3.- Domain depends on view. Solved. See here: 4.- Domain depends on generator. Solved. See here: Let's continue in another database to avoid name clashes: 5.- Computed field using table. Solved. See here: 6.- Computed field using procedure. Solved. See here: 7.- Computed field using view. Solved. See here: 8.- Computed field using generator. Solved. See here: Again, avoiding name clashes: SQL> create generator g1^ 9.- Procedure using generator. Solved. See here: 10.- Trigger using generator. Solved. See here: 11.- View using generator in SELECT part. Solved. See here: 12.- View using generator in WHERE clause. Solved. See here: 13.- Views, triggers, computed fields and domains using udfs are working as expected. However, the message is wrong. See here: Usage of generators and udfs in procedures, views and triggers is mine. Will close this entry now. There are two issues only: |
Modified by: Claudio Valderrama C. (robocop)status: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 2.1 RC1 [ 10201 ] |
Modified by: @pcisarWorkflow: jira [ 10794 ] => Firebird [ 15211 ] |
Modified by: @pavel-zotovQA Status: No test |
Submitted by: @pcisar
Assigned to: Claudio Valderrama C. (robocop)
Depends on CORE282
Is related to QA259
Votes: 1
SFID: 807869#
Submitted By: pcisar
I've logged this issue as a request for enhancement and
I hope others will append what they think IB needs
about keeping dependencies.
Following with my example script described in:
[Bug #125219] isql -a: wrong order with domains based
on table's fields
I decided to drop the procedure named "valid16" that
handles the validation for the domain "dom16". No
problem. IB destroyed it. I still was able to select
from tab16 (the one that uses the domain and it's used
by the domain at the same time), since the proc was
loaded in memory. As soon as I disconnected and
reconnected, doing a simple
select * from tab16
caused the following (expected) message:
Invalid request BLR at offset 8
procedure id 28 is not defined
I had to drop the constraint from the domain for IB
to allow me to define the proc again (or it kept
complaining about id 28), then I recreated the check
constraint.
IB keeps track of table2table dependencies through PKs
in rdb$ref_constraints. Procedures, views and triggers
that depends on tables are tracked at rdb$dependencies
and it tracks also procedure2procedure and
trigger2procedure dependencies.
What's missing, among others dependencies:
- domain using procedure
- domain using table
=> These two cases are legal despite what docos say.
- domain using generator
- domain using view
=> Subtle consequence of above findings.
- computed field using table
- computed field using procedure
- computed field using generator
- computed field using view
=> when I deleted a proc that was serving a computed
field and tried to do a SELECT from the affected table,
I got:
Invalid request BLR at offset 26
procedure <proc_name> is not defined
Interesting: in the case of a computed field, the
binding seems to be by name and not by proc number as
in a constraint, since I only defined again the proc
and it was ready, no need to drop and recreate the
computed field.
- procedure using generator
- trigger using generator
- view using generator
C.
----------------------
User: robocop
Logged In: YES
user_id=62823
Procedures using generators and UDFs are tracked now in
rdb$dependencies.
The text was updated successfully, but these errors were encountered: