Easily find issues by searching: #<Issue ID>
Example: #1832
Easily find members by searching in: <username>, <first name> and <last name>.
Example: Search smith, will return results smith and adamsmith
| Dev |
|
| QA |
|
| Priority | Low |
| Complexity | Unknown |
| Component | App - FluidShell - Command |
| Version | 12.0 |
Version: 12.0.0-rc-23-5
Build #: 29719
Build Date: 2012-Oct-12 01:27:27 PM
Using sqlexport together with source gives Failed to encode String: Pipe closed error
To reproduce, open a FluidShell to MySQL 5.5.27 database seaworld ending with host ip 56. change to database seaworld
A.) Execute below 2 queries
$:1> select * from kingdom
$:2> sqlexport -f INSERT -SS GO -TT kingdom2 | source
The below error is generated :
>[Error] Script lines: 1-4 --------------------------
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'INSERT INTO kingdom2(object_id, object_type, view_object_id, project_id, user_id' at line 2
Warnings: --->
W (1): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'INSERT INTO kingdom2(object_id, object_type, view_object_id, project_id, user_id' at line 2
<---
[Executed: 10/12/2012 1:51:51 PM] [Execution: 0ms]
source: (standard input): Script error on line 3
B.) If you execute the INSERT statements separately you can find that there is no error and using source executes correctly
$:1> select * from kingdom
$:2> sqlexport -f INSERT -SS GO -TT kingdom2 >> out.data
$:1> source out.data
C.) if you limit the number of rows read using the limit clause as in select * from kingdom limit 10 the commands work fine.
So basically in Step A, the pipe gets closed and wrong error message is displayed to the user which gives him the impression that there is something wrong with the INSERT statements
|
|
84 KB
|
9 KB
This problem has nothing to do with 'Pipe closed' message which is generated by fluid shell. The reason 'Pipe closed' message is generated is because \source ran into problem and terminated before \sqlexport. After \source terminated, \sqlexport is still running and trying to write output to pipe but the receiving end of the pipe, i.e. \source, has terminated, and hence the 'Pipe closed' error.
The root cause of the problem is because \sqlexport did not clear the SQL Buffer until it finished all of its work. This is fine in the past (before \sqlexport supports pipeline), but is no longer good any more because \sqlexport's output now can be piped to a command like \go which will read input from the SQL Buffer. As you can see, the reason \source failed is because \go actually reads the following SQL statements from the SQL Buffer:
select * from kingdom
INSERT INTO kingdom2(...)
GO
This also explains why redirect \sqlexport output to a file followed by '\source file' would work.
Fixed this problem by changing \sqlexport to clear the SQL Buffer after it reads in the SQL Buffer contents, and updates SQL History. I cannot explain why case C) works in your test case.
After this fix is applied, you can easily verify the 'Pipe closed' message by executing the following commands twice:
> select * from kingdom
> sqlexport -f INSERT -SS GO -TT kingdom2 | source
\source will terminate immaturely the second time due to duplicated key error, and hence 'Pipe closed'.
Issue #7791 |
| Closed |
| Fixed |
| Resolved |
Completion |
| No due date |
| Fixed Build trunk/29727 |
| No time estimate |
This problem has nothing to do with 'Pipe closed' message which is generated by fluid shell. The reason 'Pipe closed' message is generated is because \source ran into problem and terminated before \sqlexport. After \source terminated, \sqlexport is still running and trying to write output to pipe but the receiving end of the pipe, i.e. \source, has terminated, and hence the 'Pipe closed' error.
The root cause of the problem is because \sqlexport did not clear the SQL Buffer until it finished all of its work. This is fine in the past (before \sqlexport supports pipeline), but is no longer good any more because \sqlexport's output now can be piped to a command like \go which will read input from the SQL Buffer. As you can see, the reason \source failed is because \go actually reads the following SQL statements from the SQL Buffer:
select * from kingdom
INSERT INTO kingdom2(...)
GO
This also explains why redirect \sqlexport output to a file followed by '\source file' would work.
Fixed this problem by changing \sqlexport to clear the SQL Buffer after it reads in the SQL Buffer contents, and updates SQL History. I cannot explain why case C) works in your test case.
After this fix is applied, you can easily verify the 'Pipe closed' message by executing the following commands twice:
> select * from kingdom
> sqlexport -f INSERT -SS GO -TT kingdom2 | source
\source will terminate immaturely the second time due to duplicated key error, and hence 'Pipe closed'.