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 | Minor |
| Complexity | Unknown |
| Component | App - FluidShell |
| Version | 12.0 |
FluidShell 11.0 Type \help for a list of commands.
1> \source test.sql
select 1 /
Query not sent: server is disconnected.
2> \connect mysql-server
2> \source test.sql
select 1 /
>[Error] Script lines: 1-3 --------------------------
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 'select 1' 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 'select 1' at line 2
<---
[Executed: 3/6/2012 2:11:51 PM] [Execution: 0ms]
1> \source test.sql
select 1 /
1
----
1
1 record(s) selected [Fetch MetaData: 1ms] [Fetch Data: 0ms]
[Executed: 3/6/2012 2:11:56 PM] [Execution: 1ms]
What actually happens is that the content of the script is copied to the SQL buffer (note the 2> prompter), therefore the second \source call will fail. I don't know if this script content getting copied to visible SQL buffer is on purpose or not, but either the SQL buffer should be cleared if the \source command fails, or the \connect command should clear it.
that is the expected behavior.
From developer perspective it is an expected behavior, of course. But for novice end-users it might be unusual because FluidShell trains them that only commands that don't begin with backslash (i.e. queries) are accumulated into the SQL buffer. It is a side-effect from my point of view and might create confusion.
From developer perspective it is an expected behavior, of course. But for novice end-users it might be unusual because FluidShell trains them that only commands that don't begin with backslash (i.e. queries) are accumulated into the SQL buffer. It is a side-effect from my point of view and might create confusion.
This is a very good use case. The first question we must ask is :
1) Should the command \connect, or any other command every clear the sql buffer?
I think that the only time any command should clear the buffer, is if the command executes the buffer ... or if the command is specificly designed to clear the buffer.
The second question we should ask is :
2) If a command that is supposed to execute the buffer doesn't execute the buffer because the connection is closed, or because of some other reason, should the command clear the buffer?
I think that a command that doesn't execute the buffer should not clear the buffer regardless of the condition.
If we agree that these are correct, then the behavior is correct even if the user is confused by the behavior.
This is a very good use case. The first question we must ask is :
1) Should the command \connect, or any other command every clear the sql buffer?
I think that the only time any command should clear the buffer, is if the command executes the buffer ... or if the command is specificly designed to clear the buffer.
The second question we should ask is :
2) If a command that is supposed to execute the buffer doesn't execute the buffer because the connection is closed, or because of some other reason, should the command clear the buffer?
I think that a command that doesn't execute the buffer should not clear the buffer regardless of the condition.
If we agree that these are correct, then the behavior is correct even if the user is confused by the behavior.
Both statements are based on the pre-requisite step of script content being copied to the SQL buffer. It is an implementation detail and not obvious in the usual workflow. Untrained users are probably not aware of this step: the man, wiki page and user manual all say that the \source command "execute script from a file"; there is no reference that this command actually import script's content to SQL buffer and then execute commands accumulated into SQL buffer. Similarly, \execute or \run command also execute some specific task, but there is no import step involved and thus no confusion.
Maybe the help pages should be updated to indicate what the \source command actually does (import & execute etc).
Both statements are based on the pre-requisite step of script content being copied to the SQL buffer. It is an implementation detail and not obvious in the usual workflow. Untrained users are probably not aware of this step: the man, wiki page and user manual all say that the \source command "execute script from a file"; there is no reference that this command actually import script's content to SQL buffer and then execute commands accumulated into SQL buffer. Similarly, \execute or \run command also execute some specific task, but there is no import step involved and thus no confusion.
Maybe the help pages should be updated to indicate what the \source command actually does (import & execute etc).
I have updated the manual. The item marked in red is what is added to make it clear that source imports to SQL Buffer and executes. https://www.aquaclusters.com/app/home/project/public/aquadatastudio/wikibook/Documentation12/page/289/19.43+source
| Description | |
|
This command executes script from a file. In case of SQL scripts, the contents of the specified file are imported into the SQL buffer. When the source command encounters statement separators [ GO, go, /, @] it sends the contents of the buffer to the database and executes the accumulated commands. The source command executes an aquascript file (.xjs) within the project. For example, to execute a script named foo.xjs under the project demo which is in /home/tariq/demo, you need to change directory to /home/tariq/demo/AquaScripts and then use the command \source foo.xjs It is possible to pass command line arguments to an AquaScript (but not to a SQL script). In AquaScript, the command line arguments are passed via javascript array in an "argument" variable in the global context. |
I have updated the manual. The item marked in red is what is added to make it clear that source imports to SQL Buffer and executes. https://www.aquaclusters.com/app/home/project/public/aquadatastudio/wikibook/Documentation12/page/289/19.43+source
| Description | |
|
This command executes script from a file. In case of SQL scripts, the contents of the specified file are imported into the SQL buffer. When the source command encounters statement separators [ GO, go, /, @] it sends the contents of the buffer to the database and executes the accumulated commands. The source command executes an aquascript file (.xjs) within the project. For example, to execute a script named foo.xjs under the project demo which is in /home/tariq/demo, you need to change directory to /home/tariq/demo/AquaScripts and then use the command \source foo.xjs It is possible to pass command line arguments to an AquaScript (but not to a SQL script). In AquaScript, the command line arguments are passed via javascript array in an "argument" variable in the global context. |
Issue #6555 |
| Closed |
| Fixed |
| Resolved |
Completion |
| No due date |
| No fixed build |
| No time estimate |
that is the expected behavior.