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

Generated object is different of the source [CORE3404] #3768

Open
firebird-automations opened this issue Mar 23, 2011 · 8 comments
Open

Generated object is different of the source [CORE3404] #3768

firebird-automations opened this issue Mar 23, 2011 · 8 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Fabiano Moura (mctbrasil)

When executing one script in such a way for isql how much by the IBExpert modifying stored procedure and triggers, and in case that some transaction is opened using these objects, the system table where keeps the source is brought up to date, however, the object is not compiled. Problem big, that is not all the times that happen, but is frequently. So that this does not occur, necessary to erase the object, to create again, there yes, the object is created correctly, in accordance with the source.

@firebird-automations
Copy link
Collaborator Author

Modified by: Fabiano Moura (mctbrasil)

security: Developers [ 10012 ] =>

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Reproducible test case required

@firebird-automations
Copy link
Collaborator Author

Commented by: Fabiano Moura (mctbrasil)

Difficult to reproduce a test case. What of the one to mention, it is of facts occurred as already mentioned in the previous topic.
Example:
I have stored procedures already created that it receives some parameters from entrance, it makes some selects, some, accounts in accordance with the generated data and returns the result for the customer who called, as it is the case of "ABC Curve";. I had that to make an alteration, the source was modified in the table of system, but the object in itself not. As I know of this, therefore in the alteration, it was for correcting some problem and the problem persisted. What I had that to make. I had that to erase stored procedure and to create again with the made alteration already. Making this it functioned. This also already happened when I had that to bring up to date to trigger.
The Firebird did not return that the object was being used, executed script normally, error-free and later commit was given one normally. When verifying the source of the object, the source was with the carried through alterations, but as cited above, when executing the object, the behavior (resulted) of the same, was of as if he had not been modified the object. The behavior alone was modified, after to erase the object and to create it, that is, drop procedure object_name; commit; create procedure object_name...

I do not know if it gave to understand what I explained. But it will be the case orders the DDL of the object!
Remembering that this happens in such a way executing script it saw ISQL how much for the IBExpert.

It forgives for my English.

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

First, if you read documentation or forums or anything, then you should know that you must alter procedure in exclusive attachment, else its change could be not visible in the concurrent attachments.
Second, there was attempt to forbid such actions but users forced us to undo that change.
So, just remember that if you alter procedure (or trigger) then existing attachments will not see this change. This is true for classic servers and could not be true for SS.
In the future versions of Firebird this limittaion will be eliminated.

@firebird-automations
Copy link
Collaborator Author

Commented by: Fabiano Moura (mctbrasil)

Already I read forums, documentations and I read on what you cited. I find that I finished not citing, that this does not only happen with the bank in production, but with the data base in laboratory, and I was using, making the alteration and only have tested. Before telling to the error the they, I made a simple test, I closed the connection and April one another connection, to see if would be OK, but it was not and I do not understand because this did not occur, I only know that it occurred and must not have occurred.

In production, when it has the necessity to make some alteration, we take the care to ask for to all the users who are using some module that we know that he will go to use of direct or indirect form the object and we ask for to leave and we take the care to verify if some referring transaction open to the module exists that we ask for to leave. As already mentioned in fóruns, not I understand because the times meet transactions ghosts, that reference to no applicatory one does not have and there is opened the times for hours or days, according to tables of monitoramento of the Firebird. It can be that in the case of these transactions, either they then that it is holding the object, but as said, not of the error that is being used and as already mentioned in this topic, exactly closing the connection and opening another connection, the behavior of the object was as if it had not been brought up to date and alone after giving one drop and creating again that the same it is brought up to date.

Already I had problems in such a way twirling in version SS how much in the CS.

But I ask for excuses, in case that it has told something as primary tracker.

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

I'm sorry, but it is almost impossible to understand what do you mean exactly ;)
If you agree that you reported well known and documented issue than we can close the ticket.
If you talk about something else, you should make us understand what the issue is.

@firebird-automations
Copy link
Collaborator Author

Commented by: Fabiano Moura (mctbrasil)

It forgives, what I am telling, is the following one, I bring up to date stored procedure or to trigger, the system table is brought up to date. It close the connection with the data base, I open again, it was not object to make it or to return the data in accordance with the update? This does not occur! If I to exclude the object and to create, but at some moments, to have that to erase the object and only to create again, will be laborious, therefore the times this stored procedure is being used for others stored procedures or triggers and the parameters of entrance and exit had not moved, to have that to recriar them. What I question is the fact of because the Firebird in this in case that, it is bringing up to date the system table and pparently the object not? Therefore it is as I cited, to make the test, it close and I open the connection again.
You understand?

@firebird-automations
Copy link
Collaborator Author

Commented by: Fabiano Moura (mctbrasil)

As it is not a behavior that happens all hour, I go to see if I make more tests the document best, thus is more easy you to understand what I am saying. If to want to close the topic, all good, as soon as will have a better documentation, enters again in contact.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment