Re: sql-question

Vic Glass wrote: > (...) > #!/bin/sh > dbaccess db <<-! > unload to tbl.unl select * from tbl order by fld> ! > > vi tbl.unl # during the vi session, find and delete the desired > row(s) > vi (the gvim-rdbms edition?) - that's a good one...! Why not just use Perl and forget this whole RDBMS thing...? How about a vi blade for IUS? (/g... :) While this is certainly *a* solution, it really should be framed by a list of caveats. I would argue that a better approach would be to create a temporary index on the field(s) in question, and follow with a self-join. Exporting data out for processing is an option, but for most cases is not viable: there are existing relationships, data integrity checks, etc. The data is by and large safe within the database server, as most people put a lot of time and effort making sure of that. Taking data (especially sensitive data) out of the control of the engine should be the last thing to try... Jan

Good grief! These rows probably could be unloaded in jiffy, and the *single* row eliminated with the data reloaded quickly. There is no meaningful relationship of this data to the rest of database - there isn't even a primary key not to mentioned references! The reason not to use Perl is that its bloated. I think you need to expand your 'horizons' beyond RDMSs. Is there *anything* you do know how to do outside of SQL? While you were getting all hot and bothered about this we could have unloaded, the data, edited it and reloaded it. Clients often don't care about the nature of the solution, no matter how eloquent; they mainly care that what they needed has been done. "Jan C. Zawadzki" wrote: > Vic Glass wrote: > > > (...) > > #!/bin/sh > > dbaccess db <<-! > > unload to tbl.unl select * from tbl order by fld> > ! > > > > vi tbl.unl # during the vi session, find and delete the desired > > row(s) > > > > vi (the gvim-rdbms edition?) - that's a good one...! Why not just use Perl and > forget this whole RDBMS thing...? How about a vi blade for IUS? (/g... :) > > While this is certainly *a* solution, it really should be framed by a list of > caveats. I would argue that a better approach would be to create a temporary index > on the field(s) in question, and follow with a self-join. Exporting data out for > processing is an option, but for most cases is not viable: there are existing > relationships, data integrity checks, etc. > > The data is by and large safe within the database server, as most people put a lot > of time and effort making sure of that. Taking data (especially sensitive data) > out of the control of the engine should be the last thing to try... > > Jan