It would be helpful to know how you are deleting the observations. FSEDIT? IML?
As a general rule observations marked for deletion are removed the next time the data set is reprocessed. Such as with a PROC SORT. In IML you can use the PURGE statement.
the sql delete statement is good where the objective is conditional deletion subject to a where clause. DELETE * implies all rows, a bit like TRUNCATE.
A SAS equivalent to TRUNCATE might work with this PROC DATASETS combination [pre]option _last_ = ;
proc datasets library= &your_lib nolist ;
delete newTab / mtype= data ; * just in case it already exists ;
* now copy required structure to the new entry ;
append base=newtab data= &your_mem(obs=0) ;
* next remove old data ;
delete &your_mem / mtype= data ;
* finally rename temporary structure with original member name ;
change newtab=&your_mem ;
Append is used because it will copy all indexes and integrity constraint definitions as well as column definitions, and it uses "copy" when the base= table doesn't exist.
re: . . obs=0
I wasn't expecting to do a REORG for this poster. I assumed he wanted to truncate the table with DELETE * and release the deleted space - i.e. not just mark for deletion ...
> I have a macro that applies a DELETE * to several SAS
> tables, but the space in disk doesnt change, how can
> I really delete the records from the table, instead
> of marking them as deleted.
Of course, you may be right that I misunderstood the objective.
As to that trick with WORK.
Should the syntax be embedded in a macro, I would expect the parameter passed to be a one or two level name.
From that &name %scan( &name, -1, . ) always returns the memname, but %scan( &name, -2, . ) won't return the libname if &name is just a one-level name (implying the work library). Hence %scan( WORK.&name, -2, . ) should find WORK where there is no "." in &name.
Of course, it might catch out my accustomed approach in development where I use the user option or lib-ref to catch all one-level names in a permanent dataset ;-)