This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Delimiter statements are not being saved | ||
---|---|---|---|
Product: | db | Reporter: | Roman Mostyka <romanmostyka> |
Component: | SQL Editor | Assignee: | Jiri Skrivanek <jskrivanek> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | ||
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
Screenshot of strange looking statement in "SQL History" dialog.
create procedure after execution |
Description
Roman Mostyka
2008-10-24 16:35:21 UTC
Created attachment 72615 [details]
Screenshot of strange looking statement in "SQL History" dialog.
which databaase was used ? I tried with MySQL and Java DB. But it seems to me that it isn't so important since the problem in "SQL History" dialog I guess. This create procedure statement is valid for MySQL, not Java DB. delimiter \\ CREATE PROCEDURE p11 () BEGIN DECLARE x1 CHAR(5) DEFAULT 'outer'; BEGIN DECLARE x1 CHAR(5) DEFAULT 'inner'; SELECT x1; END; SELECT x1; END; \\ Executing against MySQL, SQL History shows the statement properly. For Java DB, since there are syntax errors, the statement looks strange in SQL History. SQL History should still list statements that failed to execute. Either please close this issue or lower the priority. I don't see a reason for lowering priority since statement isn't save correctly even if it executed successfully. John, have you tried to insert executed statement in clean SQL editor and execute this statement again? I get for posted statement following statement from "SQL History": "CREATE PROCEDURE p11 () BEGIN DECLARE x1 CHAR(5) DEFAULT 'outer'; BEGIN DECLARE x1 CHAR(5) DEFAULT 'inner'; SELECT x1; END; SELECT x1; END;;" I don't see "delimiter \\" and I don't see "\\" in the end, but I see excessive semicolon. That does look like a bug; create procedure statements need to be saved correctly. John, please see if you can reproduce what Roman is seeing. As I mentioned if the create procedure has the correct syntax and executes successfully, then History displays it correctly. Once there's a syntax error, the create procedure looks strange in History. I'm attaching a screenshot showing the create procedure with delimiter as it appears. Looks ok to me and not the same as the original screenshot. Created attachment 73017 [details]
create procedure after execution
SQL History doesn't modify the statement that had been executed. I don't think "delimiter \\" is executed. If it's expected for "delimiter \\ to be saved then this should not be filed against SQL History However, from the comments, the character of this bug is changing. First you say that the SQL looks strange, then you say that "delimiter \\" is not appearing. For me not full executed statement looks strange. ;) And I'm not sure about delimiter. On one hand it is not usual statement, but on the other hand this operator helps to execute statement successfully. Looks good to me. It seems odd that statements with syntax errors "look funny". Maybe we should only record history if the execution succeeds - why would you want to save a statement that is broken? So, now you say the only problem is "delimiter \\ .. \\" is not surrounding the create procedure statement in History ? If you think "delimiter \\ .. \\" should be saved then assign the issue to another area. Just to be clear I executed the following statement in the SQL Editor and the result is the screenshot I attached. delimiter \\ CREATE PROCEDURE p11 () BEGIN DECLARE x1 CHAR(5) DEFAULT 'outer'; BEGIN DECLARE x1 CHAR(5) DEFAULT 'inner'; SELECT x1; END; SELECT x1; END; \\
> It seems odd that statements with syntax errors "look funny". Maybe we should only record history if
the execution succeeds - why would you want to save a statement that is broken?
Other tools save statements that have syntax errors. The statement could be corrected later
I agree with John that incorrect statements also should be saved (or at least we should have such choice), since they can be inserted than and modified. John, what do you mean "then assign the issue to another area"? This problem occurs in SQL History, I can't imagine what area I should assign it to. And here is one question left: is "delimiter" should be saved or not. If yes, then this issue should be fixed. And issue #152451 also should be fixed. If no, then both these issues should be closed. But I think that delimiter should be saved, since SQL History should save statements which were executed in IDE's SQL editor rather than pure SQL, but without delimiter these statements won't work. The delimiter 'statement' is not executed, John is right, so given the current logic ("we only save executed statements") you won't see it. However, not having it can cause confusion because you may try to re-execute a statement that assumes a certain delimiter and it will fail. So I think we should fix this. It would be a small change to save the delimiter statement to history. John, I know "officially" this change would belong to the SQL editor, but if you could handle it, that would be great. You made mods to db.core already to add history when executing, this is just adding history in another place in the code. Look at db.core, org.netbeans.modules.db.sql.execute.SQLExecuteHelper.SQLSplitter.checkDelimiterStatement(). Thanks. Is this important for 7.0 ? I changed TM to 7.0 John, I agree with you that this issue should be fixed at least in 7.0. What do you think about having a fix for a next patch for 6.5? Reassigned to new owner. NB6.7 was released already - http://www.netbeans.org/community/releases/67/ Postpone fixing this issue on the next release. Delimiter will not be saved in SQL history. It is just list of executed SQL commands. |