Discussions
Categories
- 197K All Categories
- 2.5K Data
- 546 Big Data Appliance
- 1.9K Data Science
- 450.8K Databases
- 221.9K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 552 MySQL Community Space
- 479 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3.1K ORDS, SODA & JSON in the Database
- 556 SQLcl
- 4K SQL Developer Data Modeler
- 187.2K SQL & PL/SQL
- 21.4K SQL Developer
- 296.4K Development
- 17 Developer Projects
- 139 Programming Languages
- 293.1K Development Tools
- 110 DevOps
- 3.1K QA/Testing
- 646.1K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 159 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.2K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 19 Java Essentials
- 162 Java 8 Questions
- 86K Java Programming
- 81 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 205 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 471 LiveLabs
- 39 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 175 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 233 Portuguese
Use bind variables in adhoc sql similar to "execute function/procedure"

Could the same sort of bind variables be implemented for adhoc scripts as when you execute a procedure or function?
Currently, I may write a script that does
update table1 set col = '&new_val' where id = &id; update table2 set col = '&new_val' where id = &id;
And when I click run, I get prompted for new_val. Then I get prompted for id. Then I get prompted for new_val. Then I get prompted for id. This sucks... 😝
I'd rather write a script that is more like
update table1 set col = :new_val where id = :id; update table2 set col = :new_val where id = :id;
And get prompted with a single sheet asking me for values to bind to :new_val and :id. Let me choose the datatypes to bind in and set values....
Answers
-
Dislike this script-approach. It is primitive. It does not provide for proper UI interaction for and with the WIMP user.
If SQL scripts need to be executed, wrap these into an o/s scripting language like bash (Linux) or Powershell (Windows).
If UI interaction is key, use APEX, design a web page (with validation and exception handling) that enables the user to enter the data and execute the script contents via a PL/SQL post page submit process.