version 15.0.1 bug?

[Poggio, John C]

I have an extremely large data set.  Trying to MERGE two files using an active and external SPSS file.  I want to ADD VARIABLES and MATCH cases.  Everything seems to work, and the listing prior to running shows all added to VARS.  But the resultant new file only has variables contained in the active file prior to the MERGE.  Any ideas?  Thanks...

[Richard Ristow]

At 12:06 PM 3/31/2007, Poggio, John C wrote:

>Any ideas?  Thanks...

This isn't a solution, but answering these questions should help
diagnose the problem, whether it's yours or SPSS's.

I haven't heard of a bug with this behavior. It may not be one. I
respect the programmers at SPSS, Inc., but they simply haven't the
resources to make as many mistakes as we can make, out here in the
field.

>I have an extremely large data set.

It may well not matter, but "extremely large" should be quantified. How
many variables and how many cases, in each of your two files?

>Trying to MERGE two files using an active and external SPSS file.  I
>want to ADD VARIABLES and MATCH cases.  Everything seems to work, and
>the listing prior to running shows all added to VARS.  But the
>resultant new file only has variables contained in the active file
>prior to the MERGE.

You appear to be doing this from the menus, rather than writing syntax;
the language you use, is that of the menus (DATA> Merge Files> Add
Variables...).

The menus work through syntax; we'll have to see the syntax. Try it
again. Before you try it, set options as follows:

Menu Edit> Options> [tab] Viewer, check "Display commands in the log"

You probably aren't using draft output, but if you are, also set

Menu Edit> Options> [tab] Draft Viewer, check all options in "Display
Output Items"

Then, try it. After you do the merge, run a FREQUENCIES or other simple
procedure, so the files will be read and the merge completed. Then look
at the syntax in the log.

The merge syntax will be a MATCH FILES command. Look at that, and at
any error messages. If it's not clear what's wrong, post again, and
give the syntax and any error messages.

Good luck,
Richard



................
Note-WRR: test data taken from
2007-01-10 Schacht - Merge files- Add Variables.SPS

[Oliver, Richard]

It would appear to be a bug -- but one that only affects behavior when you use a combination of command syntax and the menus/dialogs. Basically, if you use command syntax to create the merged dataset, and then use the menus and dialogs to perform subsequent actions, there is an inconsistency in what the application thinks is the active dataset. To illustrate:

dataset close all.
new file.
data list free /id var1.
begin data
1 11
2 12
3 13
end data.
dataset name one.
data list free /id var2.
begin data
1 21
2 22
3 23
end data.
dataset name two.
match files file=one /file=two /by id.
dataset name merged.
dataset activate merged.
frequencies var=all.

You would expect this to produce frequency tables for three variables: id, var1, and var2 -- and that's exactly what it does in syntax. But to the menus and dialogs, the "active" dataset is still dataset one; so if, for example, you access the Frequencies dialog from the Viewer window after running the above set of commands, the Frequencies dialog variable list will only display the variables id and var1. If you click anywhere in the Data Editor window of the new dataset ("merged"), it will become the active dataset, and then the menus and dialogs will reflect the correct state.

If you use the menus and dialogs to create the merged dataset or use command syntax for all actions, the problem shouldn't occur.

-----Original Message-----
From: SPSSX(r) Discussion [mailto:[hidden email]] On Behalf Of Richard Ristow
Sent: Saturday, March 31, 2007 10:06 PM
To: [hidden email]
Subject: [BULK] Re: version 15.0.1 bug?
Importance: Low

At 12:06 PM 3/31/2007, Poggio, John C wrote:

>Any ideas?  Thanks...

This isn't a solution, but answering these questions should help
diagnose the problem, whether it's yours or SPSS's.

I haven't heard of a bug with this behavior. It may not be one. I
respect the programmers at SPSS, Inc., but they simply haven't the
resources to make as many mistakes as we can make, out here in the
field.

>I have an extremely large data set.

It may well not matter, but "extremely large" should be quantified. How
many variables and how many cases, in each of your two files?

>Trying to MERGE two files using an active and external SPSS file.  I
>want to ADD VARIABLES and MATCH cases.  Everything seems to work, and
>the listing prior to running shows all added to VARS.  But the
>resultant new file only has variables contained in the active file
>prior to the MERGE.

You appear to be doing this from the menus, rather than writing syntax;
the language you use, is that of the menus (DATA> Merge Files> Add
Variables...).

The menus work through syntax; we'll have to see the syntax. Try it
again. Before you try it, set options as follows:

Menu Edit> Options> [tab] Viewer, check "Display commands in the log"

You probably aren't using draft output, but if you are, also set

Menu Edit> Options> [tab] Draft Viewer, check all options in "Display
Output Items"

Then, try it. After you do the merge, run a FREQUENCIES or other simple
procedure, so the files will be read and the merge completed. Then look
at the syntax in the log.

The merge syntax will be a MATCH FILES command. Look at that, and at
any error messages. If it's not clear what's wrong, post again, and
give the syntax and any error messages.

Good luck,
Richard



................
Note-WRR: test data taken from
2007-01-10 Schacht - Merge files- Add Variables.SPS

[meljr]

John, first thing I would do is to make two smaller test data sets from your two orginal data files.  These will merge the same as the bigger sets and you will see your results sooner and clearer. Sometimes I get so confused with all the inner joins, outer join thinking that I just try seveal point and click senerios until I see one that works. Then save your syntax and run it on the bigger data sets. In the point and click there is also the option of using data from both files.  Test this out a bit and verify that this is not the cause of your mis-merge. Good luck, hope this helps.
meljr

Poggio, John C wrote

I have an extremely large data set.  Trying to MERGE two files using an active and external SPSS file.  I want to ADD VARIABLES and MATCH cases.  Everything seems to work, and the listing prior to running shows all added to VARS.  But the resultant new file only has variables contained in the active file prior to the MERGE.  Any ideas?  Thanks...

[Dennis Deck]

Sounds like the MATCH FILES failed and SPSS restored the original active
file.  Inspect the log for the MATCH FILES - it will probably indicate
why it failed and that the original will be restored.  If you have
specified /Map (which I recommend) there is often too much output to see
the error message without double clicking on the log.

Dennis Deck, PhD
RMC Research Corporation
[hidden email]


Poggio, John C wrote:
>
> I have an extremely large data set.  Trying to MERGE two files using
an
> active and external SPSS file.  I want to ADD VARIABLES and MATCH
cases.
> Everything seems to work, and the listing prior to running shows all
added
> to VARS.  But the resultant new file only has variables contained in
the
> active file prior to the MERGE.  Any ideas?  Thanks...
>
>

--
View this message in context:
http://www.nabble.com/version-15.0.1-bug--tf3499591.html#a9777976
Sent from the SPSSX Discussion mailing list archive at Nabble.com.

[Richard Ristow]

This continues a thread started under heading "version 15.0.1 bug?".
Richard, thank you!

At 12:06 AM 4/1/2007, Oliver, Richard wrote:

>If you use command syntax to create [a] merged dataset, and then use
>the menus and dialogs to perform subsequent actions, there is an
>inconsistency in what [SPSS] thinks is the active dataset. To
>illustrate:
>
>[variables 'id', 'var1']
>dataset name one.
>[variables 'id', 'var2']
>dataset name two.
>match files file=one /file=two /by id.
>dataset name merged.
>dataset activate merged.
>frequencies var=all.
>
>You would expect this to produce frequency tables for three variables:
>id, var1, and var2 -- and that's exactly what it does in syntax. But
>to the menus and dialogs, the "active" dataset is still dataset one.

Thank you. I don't know whether I can get away with calling this a
'bug', but it's a pretty severe 'glitch'. (A 'bug' is a deviation of
the program from its specification. A 'glitch' is a deviation from what
the specifications ought to have been.)

It seems obvious that the 'current' dataset, the one that shows up as
primary in the menus, should be the active dataset. Could this be put
on the list, as a deficiency to be fixed?

I did write 'obvious' deliberately. "'Obvious' is almost synonymous
with 'inadequately examined.'"  Perhaps there's a considered reason why
the 'current' dataset is not always the active dataset. But if so,
could the philosophy of how the 'current' dataset is determined, be
given in the documentation?

-With many thanks,
  Richard

[Poggio, John C]

Thank you, thank you, thank you...  A rose by any other name is still a....


-----Original Message-----
From: Richard Ristow [mailto:[hidden email]]
Sent: Monday, April 30, 2007 5:59 PM
To: Oliver, Richard; [hidden email]
Cc: Poggio, John C; Marks, Jim
Subject: "Active" dataset

This continues a thread started under heading "version 15.0.1 bug?".
Richard, thank you!

At 12:06 AM 4/1/2007, Oliver, Richard wrote:

>If you use command syntax to create [a] merged dataset, and then use
>the menus and dialogs to perform subsequent actions, there is an
>inconsistency in what [SPSS] thinks is the active dataset. To
>illustrate:
>
>[variables 'id', 'var1']
>dataset name one.
>[variables 'id', 'var2']
>dataset name two.
>match files file=one /file=two /by id.
>dataset name merged.
>dataset activate merged.
>frequencies var=all.
>
>You would expect this to produce frequency tables for three variables:
>id, var1, and var2 -- and that's exactly what it does in syntax. But to
>the menus and dialogs, the "active" dataset is still dataset one.

Thank you. I don't know whether I can get away with calling this a 'bug',
but it's a pretty severe 'glitch'. (A 'bug' is a deviation of the program
from its specification. A 'glitch' is a deviation from what the
specifications ought to have been.)

It seems obvious that the 'current' dataset, the one that shows up as
primary in the menus, should be the active dataset. Could this be put on the
list, as a deficiency to be fixed?

I did write 'obvious' deliberately. "'Obvious' is almost synonymous with
'inadequately examined.'"  Perhaps there's a considered reason why the
'current' dataset is not always the active dataset. But if so, could the
philosophy of how the 'current' dataset is determined, be given in the
documentation?

-With many thanks,
  Richard

[Peck, Jon]

If I understand the situation below, the gui is working correctly.

In the add/match dialogs, you are always merging one dataset (or file) TO the currently active dataset (*) - whether from a file or another open dataset.  The syntax generated by the dialog does not change the active dataset.  There is no gui equivalent to your syntax below, where you are merging two datasets to make a new active dataset and naming it merged.

Also,

-----Original Message-----
From: SPSSX(r) Discussion [mailto:[hidden email]] On Behalf Of Richard Ristow
Sent: Monday, April 30, 2007 5:59 PM
To: [hidden email]
Subject: [SPSSX-L] "Active" dataset

This continues a thread started under heading "version 15.0.1 bug?".
Richard, thank you!

At 12:06 AM 4/1/2007, Oliver, Richard wrote:

>If you use command syntax to create [a] merged dataset, and then use
>the menus and dialogs to perform subsequent actions, there is an
>inconsistency in what [SPSS] thinks is the active dataset. To
>illustrate:
>
>[variables 'id', 'var1']
>dataset name one.
>[variables 'id', 'var2']
>dataset name two.
>match files file=one /file=two /by id.
>dataset name merged.
>dataset activate merged.
>frequencies var=all.
>
>You would expect this to produce frequency tables for three variables:
>id, var1, and var2 -- and that's exactly what it does in syntax. But
>to the menus and dialogs, the "active" dataset is still dataset one.

Thank you. I don't know whether I can get away with calling this a
'bug', but it's a pretty severe 'glitch'. (A 'bug' is a deviation of
the program from its specification. A 'glitch' is a deviation from what
the specifications ought to have been.)

It seems obvious that the 'current' dataset, the one that shows up as
primary in the menus, should be the active dataset. Could this be put
on the list, as a deficiency to be fixed?

I did write 'obvious' deliberately. "'Obvious' is almost synonymous
with 'inadequately examined.'"  Perhaps there's a considered reason why
the 'current' dataset is not always the active dataset. But if so,
could the philosophy of how the 'current' dataset is determined, be
given in the documentation?

-With many thanks,
  Richard

[Richard Ristow]

At 05:50 PM 5/1/2007, Peck, Jon wrote:

>If I understand the situation below, the gui is working correctly.
>
>In the add/match dialogs, you are always merging one dataset (or file)
>TO the currently active dataset (*) - whether from a file or another
>open dataset.

So far, definitely. The MATCH FILES commands generated by the GUI
always match another file or dataset with the then-active dataset; that
is, they always have a /FILE=* or /TABLE=* subcommand.

>The syntax generated by the dialog does not change the active dataset.

That, however, does not match my experience. The following syntax is
generated and pasted from the dialog. (See complete session at the end
of this message.)

DATASET ACTIVATE ziplist.
MATCH FILES /TABLE=*
  /FILE='datafile'
  /BY UIC.

The MATCH FILES doesn't change the active dataset; MATCH FILES with
/TABLE=* (or /FILE=*) doesn't. But the DATASET ACTIVATE does, of
course.

That's the crux. The menus do not generate a merge with the dataset
that's active when they're invoked; they generate a merge with what I'm
calling the 'current' dataset, determined by some other means. In the
session below, the 'current' dataset - the dialogs call it the 'active
dataset', but it wasn't - was "ziplist", though "datafile" was active.
(The dialogs 'knew' that, too, because they knew to generate the
DATASET ACTIVATE.) As Richard Oliver described it, "there is an
inconsistency in what the application thinks is the active dataset".

It looks like the menus treat the dataset in the "front" window as
'active'. I'd suggest, rather, that they take current active dataset as
'active'.

In the meantime, for users, a work-around: always give WINDOW=FRONT on
DATASET NAME and DATASET ACTIVATE commands.
...............................................
(*) Complete session - SPSS 15.0.1 draft output:


DATASET DISPLAY.


Dataset Display
|----------------------------|---------------------------|
|Output Created              |01-MAY-2007 20:47:00       |
|----------------------------|---------------------------|

Datasets
|-----------|
|DataSet0(a)|
|-----------|
a Active dataset


DATA LIST FREE /UIC      ZIPCODE (2A5).
BEGIN DATA
30045    92127
30046    54561
END DATA.
DATASET name ziplist.
DATASET DISPLAY.


Dataset Display
|-----------------------------|---------------------------|
|Output Created               |01-MAY-2007 20:47:01       |
|-----------------------------|---------------------------|
Datasets
|----------|
|ziplist(a)|
|----------|
a Active dataset


DATA LIST FREE / ID (F8.0) UIC (A5).
BEGIN DATA
1 30045 2 30045 3 30045 4 30045 5 30045 6 30046 7 30046
END DATA.
DATASET name datafile.
DATASET Display.


Dataset Display
|-----------------------------|---------------------------|
|Output Created               |01-MAY-2007 20:47:02       |
|-----------------------------|---------------------------|
Datasets
|-----------|
|ziplist    |
|-----------|
|datafile(a)|
|-----------|
a Active dataset


EXECUTE.
DATASET Display.

Dataset Display
|----------------------------|---------------------------|
|Output Created              |01-MAY-2007 20:47:02       |
|----------------------------|---------------------------|
Datasets
|-----------|
|ziplist    |
|-----------|
|datafile(a)|
|-----------|
a Active dataset


* ... After here, it's pasted from the menus ... .
DATASET ACTIVATE ziplist.
MATCH FILES /TABLE=*
  /FILE='datafile'
  /BY UIC.
* ... No, the following LIST is hand-entered ... .
LIST.

List
|-----------------------------|---------------------------|
|Output Created               |01-MAY-2007 20:49:34       |
|----------------------------|---------------------------|
[ziplist]

UIC   ZIPCODE       ID

30045 92127          1
30045 92127          2
30045 92127          3
30045 92127          4
30045 92127          5
30046 54561          6
30046 54561          7

Number of cases read:  7    Number of cases listed:  7

[Peck, Jon]

[snip]

Here is what happens.  The dialogs show information relative to the frontend current dataset.  That's the one with the active window title bar.  Whenever you click a DE window, it becomes active IN THE FRONTEND ONLY.

When you click OK, the backend is notified of which dataset it should make active.  It does that, and it is automatically in sync with the frontend.

However, if you paste syntax, the dialog does not generate a DATASET ACTIVATE.  But when you do a Run command, the currently active DE window is activated in the backend, and, with luck, things are again in sync.

If you just save the dialog-generated syntax, or if you have activated a different dataset in the frontend inbetween pasting and running, things can be out of sync.

In SPSS 16, we are adding a control on the syntax window toolbar that shows you which dataset will be activated by your next run command.  It is a dropdown list, so if it is wrong, you can just select a different entry in the list, and that will be made active in the backend.

This may all seem rather puzzling, but it needs to work this way for several reasons.  You don't want to keep switching the backend active dataset when you click on different windows in the frontend.  And pasting an activate command every time a dialog generates syntax would balloon the quantity of generated syntax while making it very specific to the particular dataset names and thus hard to reuse.

HTH,
Jon Peck

>The syntax generated by the dialog does not change the active dataset.

That, however, does not match my experience. The following syntax is
generated and pasted from the dialog. (See complete session at the end
of this message.)

DATASET ACTIVATE ziplist.
MATCH FILES /TABLE=*
  /FILE='datafile'
  /BY UIC.

The MATCH FILES doesn't change the active dataset; MATCH FILES with
/TABLE=* (or /FILE=*) doesn't. But the DATASET ACTIVATE does, of
course.

That's the crux. The menus do not generate a merge with the dataset
that's active when they're invoked; they generate a merge with what I'm
calling the 'current' dataset, determined by some other means. In the
session below, the 'current' dataset - the dialogs call it the 'active
dataset', but it wasn't - was "ziplist", though "datafile" was active.
(The dialogs 'knew' that, too, because they knew to generate the
DATASET ACTIVATE.) As Richard Oliver described it, "there is an
inconsistency in what the application thinks is the active dataset".

It looks like the menus treat the dataset in the "front" window as
'active'. I'd suggest, rather, that they take current active dataset as
'active'.

[Richard Ristow]

Jon - THANK YOU! Below, some tests and comments. (All testing was done
with 15.0.1.) In some ways, the farther I go, the stranger it gets.

Observations:
At 12:00 PM 5/2/2007, Peck, Jon wrote:

>Here is what happens.  The dialogs show information relative to the
>frontend current dataset.  That's the one with the active window title
>bar.  Whenever you click a DE window, it becomes active IN THE
>FRONTEND ONLY.

I take it that this is the same thing, exactly, that happens when you
specify WINDOW=FRONT on DATASET NAME or DATASET ACTIVATE.

>When you click OK, the backend is notified of which dataset it should
>make active.  It does that, and it is automatically in sync with the
>frontend.

Yes, by issuing the appropriate DATASET ACTIVATE. (I've just tested
with a FREQUENCIES; I'm not pasting the output.)

>However, if you paste syntax, the dialog does not generate a DATASET
>ACTIVATE. But when you do a Run command, the currently active DE
>window is activated in the backend, and, with luck, things are again
>in sync.

Yes. That is, the DATASET ACTIVATE command is issued before selected
syntax is run. The ACTIVATE is the listing. Speaking bluntly: what you
run, isn't what you selected and thought you ran.

(The DATASET ACTIVATE *is* written to the journal; be thankful for
medium-sized favors.)

Now, to comment:

>If you just save the dialog-generated syntax, or if you have activated
>a different dataset in the frontend in between pasting and running,
>things can be out of sync.

Well, "things can be out of synch": "The pasted code doesn't work."
Even though it will appear to work, as long as SPSS knows to apply the
necessary correction before running."

>This may all seem rather puzzling, but it needs to work this way for
>several reasons.

I can see why was decided to work that way, but I don't think it needs
to.

It is puzzling. Probably, particularly to users trying to go beyond
being beginners, to understanding the system.

I think a very simple change, writing the DATASET ACTIVATE as part of
pasted code, would save a lot of the confusion, give you a cleaner
design, and lose practically nothing.

>You don't want to keep switching the (backend) active dataset when you
>click on different windows in the frontend.

Of course you don't want to. But you also wouldn't need to. There's no
reason to switch (to generate DATASET ACTIVATE) until running or
pasting syntax. And when that happens the system must switch, as it
already does.

>And pasting an activate command every time a dialog generates syntax
>would balloon the quantity of generated syntax while making it very
>specific to the particular dataset names and thus hard to reuse.

But there's no question of having to do that. The front end need only
'remember' what ACTIVATE it last issued, not generate ones that are
therefor unnecessary. It does that already: I checked, and it doesn't
issue further ACTIVATEs after it's issued one in response to OK from a
dialog box, or Run from a syntax window.

>In SPSS 16, we are adding a control on the syntax window toolbar that
>shows you which dataset will be activated by your next run
>command.  It is a dropdown list, so if it is wrong, you can just
>select a different entry in the list, and that will be made active in
>the backend.

OK, but that leaves: The code Run runs, is not the code that you
selected and thought you ran.

So the documentation for the Run command is wrong:

"The Run button on the Syntax Editor toolbar runs the selected commands
or the command where the cursor is located if there is no selection."
-SPSS 15 Base User's Guide, p.266

And SPSS pastes code that won't work.

If this isn't confusing, what would be?

Now, the way datasets behave from the command environment isn't too
bad. The CSR documentation for the DATASET xxx commands has it right.

It's handling of datasets in the menus that gets complicated. There's
now both what I'll call a 'foreground' dataset (the one brought to the
fore by clicking, or by a WINDOW=FRONT subcommand) and an 'active'
dataset (as described in the CSR). When they're different, there's
added complexity in the relationship between the menus and commands.

It's a true complication, not to be resolved simply by clearer
explanations. Even the Base User's Guide has it wrong:

"You can change the active dataset simply by clicking anywhere in the
Data Editor window of the data source that you want to use or by
selecting the Data Editor window for that data source from the Window
menu." (p.99)

No; it's the 'foreground' dataset that's changed. That also applies to

"When you first open a data source, it automatically becomes the active
dataset." (ibid,p.98)

which is incorrect as it stands, but correct if 'foreground' is
substituted.

Perhaps the Base User's Guide should use 'foreground' throughout. But
then, somewhere, there'd need to be a clear definition of 'foreground'
and 'active' datasets, and their distinction. (NOT in the pages where
new users are first introduced to datasets! How about in the Universals
section of the Command Syntax Reference? "All SPSS commands run on the
active dataset. The menus generate commands for the foreground dataset,
the one in the front window, and if necessary generate syntax to make
it active.")

That all makes more complicated documentation. Quite true. But it's not
obfuscating something; it's bringing out and explaining a true
complexity in the system.

-Many thanks to all,
  Richard

[Richard Ristow]

All this time and work, and I'm still learning things about this.

(If you're coming in in the middle: this thread is about what looked
like paradoxes in how the menus, the GUI, work with multiple open
datasets, in SPSS 14 and 15. Our story so far:

At any point in an SPSS session, one dataset is *active*. The active
dataset has the role of the *working file* in earlier SPSS versions:
all SPSS commands apply to it, except where they explicitly name
another file or dataset, e.g. on a FILE= subcommand. Managing datasets,
particularly determining which dataset is active, is documented in the
articles on the "DATASET" commands in the SPSS Command Syntax
Reference.

At any point, there is also one *foreground* dataset (my terminology,
not SPSS standard). The foreground dataset is the one in the front
window, as determined by user action or DATASET commands. The
foreground dataset and active dataset need not be the same, though
specifying WINDOW=FRONT on DATASET NAME or DATASET ACTIVATE places the
active dataset in the foreground.

The menus generate commands for the foreground dataset; that is,
commands that run properly provided that the then-foreground dataset is
active. When a command is run from the menus, a DATASET ACTIVATE
command is also run, if necessary, to make the foreground dataset
active.

When syntax is pasted from the menus, the corresponding DATASET
ACTIVATE command is *not* included. This has been addressed by a change
to the functionality of the Run command that runs syntax from a syntax
window: when syntax is selected and run, if the current foreground
window is not active, Run issues (but does not paste) a DATASET
ACTIVATE command to activate it. (I am not aware that this has been
documented.)

However, often the syntax thus pasted will fail, if saved, reloaded,
and run, because the dataset to which it refers is then NOT active.)


Continuing:

At 01:30 PM 5/3/2007, Richard Ristow wrote:

>At 12:00 PM 5/2/2007, Peck, Jon wrote:
>
>>However, if you paste syntax, the dialog does not generate a DATASET
>>ACTIVATE. But when you do a Run command, the currently "active"
>>[i.e., 'foreground'] Data Editor window is activated and, with luck,
>>things are again in sync.
>>
>>If you save the dialog-generated syntax, or if you have "activated"
>>[i.e., made 'foreground'] a different dataset in between pasting and
>>running, things can be out of sync [and the syntax may not work].
>>
>>This may all seem rather puzzling, but it needs to work this way for
>>several reasons. [...]
>>
>>Pasting an activate command every time a dialog generates syntax
>>would balloon the quantity of generated syntax while making it very
>>specific to the particular dataset names and thus hard to reuse.

Here, I think I understand more than when I last wrote. I wrote then,

>There's no question of having to do that. The front end need only
>'remember' what ACTIVATE it last issued, not generate ones that are
>therefor unnecessary. It does that already: I checked, and it doesn't
>issue further ACTIVATEs after it's issued one in response to OK from a
>dialog box, or Run from a syntax window.

What I missed, here, is that the front end (the GUI, the menus)
probably *doesn't* 'remember' what DATASET ACTIVATE it last issued. The
menu system has access to the active data dictionaries (that's how it
generates lists of variables to select from), and of course it 'knows'
which window is in front. When issuing commands (as opposed to pasting
them), that's enough. There are no unexecuted commands to take into
account, so it need only issue a DATASET ACTIVATE if the foreground
dataset is not active *at that moment*. When pasting syntax, the
choices are more difficult, including

(a) Paste a DATASET ACTIVATE every time it pastes syntax and the
foreground dataset is not active ("paste an activate command every time
a dialog generates syntax"). This is the course that Jon mentions, and
deprecates. (Jon, apologies if I'm misunderstanding or misrepresenting
you.) However, for all its drawbacks, it at least pastes code that, if
saved, reloaded, and rerun in the original environment, will work. Or,

(b) 'Remember' what DATASET ACTIVATE it last pasted and, if it would
activate the current 'foreground' dataset, not paste another one. This
is what I thought the natural thing to do. I still think it has a lot
to recommend it; but if I now understand correctly, it would be a
significant new feature for the front end (GUI);

(c) Paste the syntax, ignoring the possible need for a DATASET
ACTIVATE; issue the DATASET ACTIVATE when syntax is selected and run.
This is what is done now, which I deprecate;

(d) (a possibility not previously mentioned) When running pasted
syntax, if issuing a DATASET ACTIVATE, also paste in the DATASET
ACTIVATE preceding the syntax that is run. (While at best a half
measure, that would produce a working syntax file in many simple cases;
and would give some warning, in the form of that DATASET ACTIVATE, in
many more.)
....................
It is easy to be glib about what should happen at other people's design
meetings. I don't want to do that, about the many meetings about
datasets that must have taken place at SPSS, Inc.

Having a 'foreground' dataset (JP: "active in the frontend")
independent of the 'active' dataset (JP: "active in the backend")
introduces genuine complexities and confusions. I can suggest some
things I think will help (I have), but I have no resolution I think
definitive.

However, were I at those design meetings, I'd say this: Whatever design
difficulties I found myself in, I'd take almost any step rather than
have my system generate some of its own code, and pass it to the user
as working code, when it is code that does not work as generated and
saved.

-With the greatest of regards and good wishes,
  Richard

[Bethany Cockburn]

Hi!  We are considering upgrading to SPSS Builder 4.0 because our 3.0 forms
have been corrupting frequently.  Our university already owns the software,
so cost isn't the issue as much as running two versions of Builder.  Do any
of you have an opinion about 4.0 versus 3.0?

Thanks for any insights!!
Bethany



Bethany S. Cockburn, M.A.
Data Specialist
Child Assessor
University of Notre Dame
Data Management Center
Psychology Department
944 Flanner Hall
Notre Dame, IN 46556
574-631-0943