Vim Tips Wiki
Register
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===
+
==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