No edit summary |
Tag: sourceedit |
||
(7 intermediate revisions by 5 users not shown) | |||
Line 2: | Line 2: | ||
==Comments== |
==Comments== |
||
+ | ===DBI=== |
||
+ | From the Perl documentation for the DBI prepare method (https://metacpan.org/pod/DBI#prepare): |
||
+ | |||
+ | <blockquote>Some command-line SQL tools use statement terminators, like a semicolon, to indicate the end of a statement. Such terminators should not normally be used with the DBI.</blockquote> |
||
+ | Including the command terminator (by default a semicolon) as part of the SQL is causing parse and execute errors for DBD::Oracle such that I'm not able to make use of DBI, which I would much prefer because of its speed and formatting of output. I'm not sure what the best fix is... as you would want semicolons if sending a pl/sql block (anonymous block or some kind of CREATE). Oracle SQL*Plus uses a slash ("/") to terminate pl/sql blocks, but allows semicolons as statement terminators for SQL statements. |
||
+ | --[[User:Jwss|Jwss]] ([[User talk:Jwss|talk]]) 17:16, April 4, 2016 (UTC) |
||
+ | --------- |
||
+ | |||
Thanks for this great plugin, use it almost everyday. Have one request, would be great if variable can be use instead of parameters prompting, i.e: |
Thanks for this great plugin, use it almost everyday. Have one request, would be great if variable can be use instead of parameters prompting, i.e: |
||
<pre> |
<pre> |
||
Line 15: | Line 23: | ||
:Not sure which version of dbext you are using. By default, when executing the SELECT statement it will prompt you for :opt1 and :opt2. It will then also save these values (for this buffer) and the next time you execute the a query using :opt1 or :opt2, it will ask if you want to use your saved values. You can see the saved values (and delete them) using <Leader>slr (SQL - List - vaRiables). That feature was added in version 11.1, the current version is 14.0 [[User:Dfishburn|Dfishburn]] 11:45, April 5, 2012 (UTC) |
:Not sure which version of dbext you are using. By default, when executing the SELECT statement it will prompt you for :opt1 and :opt2. It will then also save these values (for this buffer) and the next time you execute the a query using :opt1 or :opt2, it will ask if you want to use your saved values. You can see the saved values (and delete them) using <Leader>slr (SQL - List - vaRiables). That feature was added in version 11.1, the current version is 14.0 [[User:Dfishburn|Dfishburn]] 11:45, April 5, 2012 (UTC) |
||
− | + | ==Bugs== |
|
+ | ===Version 23=== |
||
+ | *In the function dbext#DB_commit there is a bug around line 9228. |
||
+ | <pre> |
||
+ | perl db_commit(bufnr) |
||
+ | </pre> |
||
+ | |||
+ | should be |
||
+ | <pre> |
||
+ | exec "perl db_commit(". bufnr . ")" |
||
+ | </pre> |
||
+ | |||
+ | :"bufnr" was being passed to Perl as a literal string "bufnr" instead of the buffer number. |
||
+ | |||
+ | *I also found some naked db_debug() calls (the calling procedure wasn't part of the string passed to db_debug()) that made debugging a little more difficult. I'll try to diff my changes and post line numbers later -- or better yet figure out how to work with github and make a pull request. |
||
+ | --[[User:Jwss|Jwss]] ([[User talk:Jwss|talk]]) 14:42, April 4, 2016 (UTC) |
||
+ | |||
*Version 20 does not prompt for connection profile |
*Version 20 does not prompt for connection profile |
||
:I have two Mysql connection profile in my .vimrc file, works fine with v19. After upgrading to v20. dbext does not prompt for connection profile, I have to issue "\sbp" to select connection first otherwise it will display error "dbext:A valid database type must be chosen" |
:I have two Mysql connection profile in my .vimrc file, works fine with v19. After upgrading to v20. dbext does not prompt for connection profile, I have to issue "\sbp" to select connection first otherwise it will display error "dbext:A valid database type must be chosen" |
||
Line 85: | Line 109: | ||
* Update: Version 20.0 still has syntax highlighting removed in certain cases as the previous poster pointed out. This is reproducible following the same steps earlier listed. Enter <code>:cope<CR><C-w>k<C-w>o</code> --July 30, 2014 |
* Update: Version 20.0 still has syntax highlighting removed in certain cases as the previous poster pointed out. This is reproducible following the same steps earlier listed. Enter <code>:cope<CR><C-w>k<C-w>o</code> --July 30, 2014 |
||
+ | |||
+ | ==How to edit stored functions in Postgres?== |
||
+ | |||
+ | Thanks for this great plugin! I'm trying to figure out how to define a pl/pgsql function, it doesn't appear that dbext will allow SQL commands having more than one semicolon, for example: |
||
+ | <pre> |
||
+ | CREATE OR REPLACE FUNCTION example_function() returns integer as $$ |
||
+ | begin |
||
+ | return 42; |
||
+ | end |
||
+ | $$ language plpgsql; |
||
+ | </pre> |
||
+ | |||
+ | When I run \sel it appears to only send the portion up to the first semi-colon, is there a way to send the entire visually selected area? -- Ed September 18, 2015 |
||
+ | |||
+ | ==Problems deleting unsaved buffer== |
||
+ | In dbext v12 and later versions, deleting an unsaved buffer does not work if other buffers are open. Assume a .vimrc with only <code>set nocompatible</code> in it and dbext installed, nothing else. I am using vim 7.4.415: |
||
+ | * Start vim |
||
+ | * In the empty buffer window, type something in order to modify it. (Do not save.) |
||
+ | * Open a second buffer with some existing file, e.g., <code>:sp ~/.vimrc</code> |
||
+ | * Switch back to the first buffer: <code>CTRL-w w</code>. At this point, <code>:ls</code> shows |
||
+ | <pre> 1 %a + "[No Name]" line 1 |
||
+ | 2 #a "~/.vimrc" line 0</pre> |
||
+ | * Attempt to close the current buffer: <code>:bd!</code> |
||
+ | |||
+ | Result: ''Buffer 2 with .vimrc becomes hidden, and the first buffer remains unclosed.'' <code>:ls</code> shows: |
||
+ | <pre> |
||
+ | 1 %h + "[No Name]" line 1 |
||
+ | 2 # "~/.vimrc" line 1 |
||
+ | </pre> |
||
+ | |||
+ | The ls output is rather strange, since ls indicates buffer 1 would be hidden, whereas in fact it is not. |
||
+ | |||
+ | Without dbext, or with dbext v11 installed, the first buffer is correctly deleted, and the buffer list is: |
||
+ | <pre> |
||
+ | 2 %a "~/.vimrc" line 1 |
||
+ | </pre> |
||
+ | |||
+ | If I change <code>plugin/dbext.vim</code> to use the old s:DB_checkModeline implementation, it works as expected (see patch at https://gist.github.com/andreaswachowski/c01f044e81d84f4dedce ). It seems weird, because this change from v11 to v12 looked more like a refactoring, but apparently it isn't. I would appreciate if someone can confirm the behavior and, ideally, include a fix in an upcoming dbext.vim version. Thanks! |
||
+ | |||
+ | ==Describing, Selecting from non-current database== |
||
+ | I'm using Sybase ASE and would like a way to describe (for example) a table which is not in the current database, e.g. |
||
+ | otherdb.dbo.mytable |
||
+ | I've tried <leader>sdt both in visual and normal mode, but cannot get this to work. --February 3, 2015 |
Revision as of 17:16, 4 April 2016
Use this page to discuss script 356 dbext: database access from Vim
- Add constructive comments, bug reports, or discuss improvements (see the guideline).
- Do not document the script here (the author should do that on vim.org).
- This page may be out of date: check the script's vim.org page above, and its release notes.
Comments
DBI
From the Perl documentation for the DBI prepare method (https://metacpan.org/pod/DBI#prepare):
Some command-line SQL tools use statement terminators, like a semicolon, to indicate the end of a statement. Such terminators should not normally be used with the DBI.
Including the command terminator (by default a semicolon) as part of the SQL is causing parse and execute errors for DBD::Oracle such that I'm not able to make use of DBI, which I would much prefer because of its speed and formatting of output. I'm not sure what the best fix is... as you would want semicolons if sending a pl/sql block (anonymous block or some kind of CREATE). Oracle SQL*Plus uses a slash ("/") to terminate pl/sql blocks, but allows semicolons as statement terminators for SQL statements. --Jwss (talk) 17:16, April 4, 2016 (UTC)
Thanks for this great plugin, use it almost everyday. Have one request, would be great if variable can be use instead of parameters prompting, i.e:
set opt1 = "somevalue"; opt2 = "somevalue2" set opt1 = "othervalueset"; opt2 = "othervalueset2" SELECT * from imaginarytable WHERE field1 = :opt1 AND field2 = :opt2;
So one can select different value before executing above query. Thanks for great plugin. --JK October 27, 2011
- Not sure which version of dbext you are using. By default, when executing the SELECT statement it will prompt you for :opt1 and :opt2. It will then also save these values (for this buffer) and the next time you execute the a query using :opt1 or :opt2, it will ask if you want to use your saved values. You can see the saved values (and delete them) using <Leader>slr (SQL - List - vaRiables). That feature was added in version 11.1, the current version is 14.0 Dfishburn 11:45, April 5, 2012 (UTC)
Bugs
Version 23
- In the function dbext#DB_commit there is a bug around line 9228.
perl db_commit(bufnr)
should be
exec "perl db_commit(". bufnr . ")"
- "bufnr" was being passed to Perl as a literal string "bufnr" instead of the buffer number.
- I also found some naked db_debug() calls (the calling procedure wasn't part of the string passed to db_debug()) that made debugging a little more difficult. I'll try to diff my changes and post line numbers later -- or better yet figure out how to work with github and make a pull request.
--Jwss (talk) 14:42, April 4, 2016 (UTC)
- Version 20 does not prompt for connection profile
- I have two Mysql connection profile in my .vimrc file, works fine with v19. After upgrading to v20. dbext does not prompt for connection profile, I have to issue "\sbp" to select connection first otherwise it will display error "dbext:A valid database type must be chosen"
- Syntax highlight got removed after some actions sequence if dbext plugin installed.
- Steps to reproduce: open some file to edit. Enter
:cope<CR><C-w>k<C-w>o
--January 25, 2012
- I can't reproduce this. If you can using the current version 14.0 please email me, as it will involve some back and forths. Dfishburn 11:45, April 5, 2012 (UTC)
- Using DBext from VIM on Microsoft Windows XP with Oracle Instant Client 11.2adds a single quote when it should add a double-quote. The command arguments sent to SQLPLUS do not get properly expanded and the command fails. Changing the code from
# Single quote causing problem # | # * sqlplus -S 'my_user/my_password@oracle_server" @c:\temp/dbext.sql
to
# Substituting double quote solves problem # | # * sqlplus -S "my_user/my_password@oracle_server" @c:\temp/dbext.sql
fixes the problem. Of course, this makes DBext useless unless there is a fix for this behavior. Elcidia 17:37, June 12, 2012 (UTC)
- A fix (version 16.0) for this was posted last night, please upgrade to the most current release of dbext. Dfishburn 21:58, June 12, 2012 (UTC)
- Update: Still not working for Windows command interpreter
I installed version 16.0 and I see that two single quotes are now issued to the command line. Unfortunately, on Windows, these should be double quotes and not single quotes. This is a limitation of the Windows as the command interpreter does not process single quotes (been that way since Windows 3.1 I think).
# What it should look like # double quote double quote # | | # + + sqlplus -S "my_user/my_password@oracle_server" @c:\temp/dbext.sql
As another idea, it would be cool if Powershell could be invoked. Elcidia 13:30, June 13, 2012 (UTC)
- Update: Version 17.0 is also not working with the Windows command interpreter for the reasons mentioned by @Elcidia.
Changing
let cmd = dbext_bin . \ ' ' . dbext#db_getwtype("cmd_options") . \ s:db_option(" '", s:db_get("user"), '') . \ s:db_option('/', s:db_get("passwd"), '') . \ s:db_option('@', s:db_get("srvname"), '') . \ s:db_option(' ', dbext#db_getwtypedefault("extra"), '') . \ "' @" . s:dbext_tempfile
to
let cmd = dbext_bin . \ ' ' . dbext#db_getwtype("cmd_options") . \ s:db_option(" \"", s:db_get("user"), '') . \ s:db_option('/', s:db_get("passwd"), '') . \ s:db_option('@', s:db_get("srvname"), '') . \ s:db_option(' ', dbext#db_getwtypedefault("extra"), '') . \ "\" @" . s:dbext_tempfile
in autoload/dbext.vim (ORA exec section) fixed the problem for me. --October 19, 2012
This change is definitely in version is 21.0 Dfishburn 10:00, October 29, 2013 (UTC)
- Update: Version 20.0 still has syntax highlighting removed in certain cases as the previous poster pointed out. This is reproducible following the same steps earlier listed. Enter
:cope<CR><C-w>k<C-w>o
--July 30, 2014
How to edit stored functions in Postgres?
Thanks for this great plugin! I'm trying to figure out how to define a pl/pgsql function, it doesn't appear that dbext will allow SQL commands having more than one semicolon, for example:
CREATE OR REPLACE FUNCTION example_function() returns integer as $$ begin return 42; end $$ language plpgsql;
When I run \sel it appears to only send the portion up to the first semi-colon, is there a way to send the entire visually selected area? -- Ed September 18, 2015
Problems deleting unsaved buffer
In dbext v12 and later versions, deleting an unsaved buffer does not work if other buffers are open. Assume a .vimrc with only set nocompatible
in it and dbext installed, nothing else. I am using vim 7.4.415:
- Start vim
- In the empty buffer window, type something in order to modify it. (Do not save.)
- Open a second buffer with some existing file, e.g.,
:sp ~/.vimrc
- Switch back to the first buffer:
CTRL-w w
. At this point,:ls
shows
1 %a + "[No Name]" line 1 2 #a "~/.vimrc" line 0
- Attempt to close the current buffer:
:bd!
Result: Buffer 2 with .vimrc becomes hidden, and the first buffer remains unclosed. :ls
shows:
1 %h + "[No Name]" line 1 2 # "~/.vimrc" line 1
The ls output is rather strange, since ls indicates buffer 1 would be hidden, whereas in fact it is not.
Without dbext, or with dbext v11 installed, the first buffer is correctly deleted, and the buffer list is:
2 %a "~/.vimrc" line 1
If I change plugin/dbext.vim
to use the old s:DB_checkModeline implementation, it works as expected (see patch at https://gist.github.com/andreaswachowski/c01f044e81d84f4dedce ). It seems weird, because this change from v11 to v12 looked more like a refactoring, but apparently it isn't. I would appreciate if someone can confirm the behavior and, ideally, include a fix in an upcoming dbext.vim version. Thanks!
Describing, Selecting from non-current database
I'm using Sybase ASE and would like a way to describe (for example) a table which is not in the current database, e.g. otherdb.dbo.mytable I've tried <leader>sdt both in visual and normal mode, but cannot get this to work. --February 3, 2015