Running V11.5.2.1 and seems as though the
Temp.
Select If(var=1).
SAVE OUTFILE='C:\Scores.sav'
/COMPRESSED.
Type syntax isn't working.
Anyone else noticed this? Or that my syntax is 'goofy?'
S
Temp.
Select If(var=1).
SAVE OUTFILE='C:\Scores.sav'
/COMPRESSED.
Type syntax isn't working.
Anyone else noticed this? Or that my syntax is 'goofy?'
S
SAVE OUTFILE='C:\Scores.sav'/unselected delete.
> Temp.
> Select If(var=1).
> SAVE OUTFILE='C:\Scores.sav'
> /COMPRESSED.
> Type syntax isn't working.
> Anyone else noticed this? Or that my syntax is 'goofy?'
> S
Temp.
Select If(group=1).
SAVE OUTFILE='C:\Scores.sav'
/UNSELECTED=DELETE
/COMPRESSED.
> SAVE OUTFILE='C:\Scores.sav'/unselected delete.
> > Running V11.5.2.1 and seems as though the
> > Temp.
> > Select If(var=1).
> > SAVE OUTFILE='C:\Scores.sav'
> > /COMPRESSED.
> > Type syntax isn't working.
> > Anyone else noticed this? Or that my syntax is 'goofy?'
> > S
[ ... ]Quote:> Still doesn't work as ...?
> Temp.
> Select If(group=1).
> SAVE OUTFILE='C:\Scores.sav'
> /UNSELECTED=DELETE
> /COMPRESSED.
I can't say why that does not work, but here is
an alternative.
Do if (group eq 1) .
xsave outfile= 'c:\scores.sav' /compressed .
else .
xsave outfile= ... .
end if .
execute .
When I want just one part, I'm very often going to use the
other part, too, so I use syntax like this on a regular basis.
I almost never use "temporary" any more -- it was handy,
but in the long run, I think it was a bit confusing. These days,
I am likely to save a full file, then select and process it, then
re-open in order to go back to the original. It might leave the
documentation easier to read, or leave me less to explain to
other people,
--
http://www.pitt.edu/~wpilib/index.html
"Taxes are the price we pay for civilization." Justice Holmes.
Quote:> Running V11.5.2.1 and seems as though the
> Temp.
> Select If(var=1).
> SAVE OUTFILE='C:\Scores.sav'
> /COMPRESSED.
> Type syntax isn't working.
> Anyone else noticed this? Or that my syntax is 'goofy?'
> S
V11.5 works
V11.5.1 works
V11.5.2.1 fails
SPSS Tech is working on it
WMB
> > Running V11.5.2.1 and seems as though the
> > Temp.
> > Select If(var=1).
> > SAVE OUTFILE='C:\Scores.sav'
> > /COMPRESSED.
> > Type syntax isn't working.
> > Anyone else noticed this? Or that my syntax is 'goofy?'
> > S
1. HELP: Deadlocking system tables (aggregate functions, temp tables, select into)
Hiya folks,
The application:
We have implemented a real time material handling system with 50
clients and one server. We do in the neighborhood of 800,000
transactions a day. All apps are written in C++, and we have 2 types
of access methods for the DB: RecordSets for most load/store actions
of our objects, and Direct ODBC for high performance areas of the
system (we got from 4X-60X increase in performance by optimizing these
areas w/ stored procedures and direct ODBC Calls). Each application
maintains 2 connections at all times to the server (one each for
RecordSets and Direct ODBC)
The system:
Most clients are 486/33s with the odd P100 mixed in. The server is an
IBM quad PPro. We are using MS SQLServer 6.5. Clients use win95,
Server is NT3.51.
The problem:
We are encountering hundreds of deadlocks every day (sometimes in the
thousands). Now I'd expect to run into deadlocks in a high volume
system like this, but the problem is that, according to MS tech
support, I'm getting deadlocks from tempdb system tables when I create
temp tables. This deadlock can occur between 2 select statements that
are _not_ enclosed in transactions, as long as they use aggregate
functions.
I'll try to restate that: According to MS, any time I do anything
that causes a temp table to be created (SELECT INTO, Use Aggregate
functions, CREATE TABLE #TableName, ORDER BY, etc.) there is a
possibility that the statement may conflict with another temp table
creator and deadlock. (again for clarity: not block..._Deadlock_)
Excuse my surprise, but this sounds wrong to me. From my
understanding, deadlocks require 2 transactions, at least one
exclusive lock, one or more shared locks, and at least a total of 4
locks.
Our situation has no transactions (other than the implicit atomic tran
that surrounds the selects) no exclusive locks (other than implicit
locks caused when the temp tables are created), and only one resource
in common (the system table accessed to create the temp tables).
3 questions:
1) why isnt resource contention for the system table for creating
temps handled better?
2) is this normal? Do all SQL Database Systems have this problem?
(meaning do I just need to get used to it?)
3) what can I do about it?
Also, if all is as it should be, then can any of you help me to
understand why the server allows this to happen. It seems like this
would have been something simple for the server to handle, and I'm
quite frankly dumbfounded that this is a problem in a modern DBMS.
_Any_ imput (even if its only that I'm just naive) would be very
appreciated.
-Lee
----
"It can't rain all the time"
3. SELECT FROM t1 WHERE id IN (SELECT id FROM t2 UNION SELECT id
4. ICES98: Second Call for Papers
5. SELECT FROM t1 WHERE id IN (SELECT id FROM t2 UNION SELECT id FROM t3)
7. CA400/WIN95 Timeout Problem
9. Help - Excel 5 function (VLOOKUP)/nested IFs
10. comparing: ifs, dct, wl, vc...
11. Q: where to get more IFS codes?