Thank you very much to those who responded, and to those that didn't here is an 
interesting lesson to tuck away for future reference.
The answer eventually came from none other than MapInfo.

The explanation from Eric below describes the problem exactly, and the remedy worked. 
In fact I was just about to write about yet another issue about an error I have been 
getting trying to write workspaces, and Eric's reply circumvented that (you can't 
complain about that sort of service).

I eventually worked around the first isue about saving queries in workspaces by 
writing the whole workspace to create the map as a file, and then opening the 
workspace 
file up before doing further alterations to it -  essentially a long winded "run 
command" approach, but it worked. 

 Erics's explanation also explained why in my real application that I was getting one 
query saved, but not others.  This was caused by the first select string being created 
by 
building the SQL string up from a number of variables (including arrays), while the 
second being run directly using variables.  I missed it because I was thinking that it 
was 
caused by the first table being Access based, and therefore requiring a version 5 
workspace - and that having something to do with saving queries.  Silly in hindsight.

Anyway, the short answer is that if you want to create a map that has queries in it - 
and allow a user to save this to a workspace for later use - you should build the SQL 
into 
a string and use the run command command.

Then if you want to save a workspace that has queries in it, you should write the save 
workspace command as a string and use the run command to execute it.

Robert.



26/1/2002 11:28:27 AM, [EMAIL PROTECTED] wrote:

>
>I could not reproduce your exact scenario in that in my attempts show that
>any select done directly via MapBasic will not be saved in a workspace. The
>problem stems from the fact that SQL selects compiled into MapBasic are not
>properly de-compiled into their string form to be saved in the workspace.
>Selects done via a Run Command, however, are saved as they are never
>compiled,  Also, some of the behavior described below would be different if
>you have the preference set to NOT save queries in workspaces. See Options,
>Preferences, Startup for that setting.
>
>If I compile the following purposefully lazy code, lazy in that I am not
>even specifying selection or any other things like I perhaps should.
>Keeping the code really simple.
>
>Close all
>Open Table "states" Interactive
>Select * from states where state="NY"
>Map From selection
>
>
>If I run this, I have a map of NY State.
>
>If I save the workspace from the user interface, and type it out I get the
>following:
>
>!Workspace
>!Version 400
>!Charset WindowsLatin1
>Open Table "C:\MIPRO65\DATA\Tut_Data\Tut_Usa\USA\states" As states
>Interactive
>
>The query and therefore the layer created from the query and therefore the
>map whose only layer was the query layer do not exist!
>
>
>However, if I change my code so that rather than a select I do a Run
>Command of the select string I get the same result but the query, layers
>and map are saved in to workspace.
>
>Close all
>Open Table "states" Interactive
>run command "Select * from states where state=""NY"""
>Map From selection
>
>!Workspace
>!Version 600
>!Charset WindowsLatin1
>Open Table "C:\MIPRO65\DATA\Tut_Data\Tut_Usa\USA\states" As states
>Interactive
>Select *  from states  where state = "NY"
>Map From Query1
>  Position (0.0520833,0.0520833) Units "in"
>  Width 5.29167 Units "in" Height 3.25 Units "in"
>Set Window FrontWindow() ScrollBars Off Autoscroll On
>Set Map
>  CoordSys Earth Projection 1, 62
>  Center (-75.809411,42.7545665)
>  Zoom 508.0336642 Units "mi"
>  Preserve Zoom Display Zoom
>  Distance Units "mi" Area Units "sq mi" XY Units "degree"
>Set Map
>  Layer 1
>    Display Graphic
>    Label Line None Position Center Font ("Arial",0,9,0) Pen (1,2,0)
>      With State_Name
>      Parallel On Auto Off Overlap Off Duplicates On Offset 2
>      Visibility On
>
>
>Another instance of the same problem, I believe, is seen by attempting to
>save a workspace from MapBasic when a query table exists.  I have seen the
>error "Unable to Save Workspace" come up.
>For example, the following:
>
>Close all
>Open Table "states" Interactive
>run command "Select * from states where state=""NY"""
>Map From selection
>Save workspace as "nyselect.wor"
>
>If I follow the same logic I can use the run command to save the workspace.
>
>Close all
>Open Table "states" Interactive
>run command "Select * from states where state=""NY"""
>Map From selection
>Run Command "Save workspace as ""nyselect.wor"""
>
>However, while I get no error creating the workspace, because I was lazy
>about the into table, the name of the query table may not exist.
>
>To make it all work you need to specify the into table
>
>Close all
>Open Table "states" Interactive
>run command "Select * from states where state=""NY"" into foo"
>Map From foo
>Run Command "Save workspace as ""nyselect.wor"""
>
>
>This behavior is from the same root cause as the limitation documented
>under the Commit Table statement in the MapBasic help for the QUERY type.
>
>To save a Query use the QUERY type for the table. Only queries made from
>the user interface and queries created from Run Command statements in
>MapBasic are able to be saved.
>
>
>Try the workaround of using Run Command. I have not seen a case where it
>would fail and it explains why your code worked when running the selects
>from the SQL Select dialog. We will investigate a solution to the problem.
>
>Eric Blasenheim
>Software Architect
>MapInfo Corporation
>
>
>

Robert Crossley 
Robert Crossley & Associates
9 Short St
New Brighton NSW 2483

P: 02 6680 1309
F: New Connection
M: 0419 718 642
E: [EMAIL PROTECTED]




_______________________________________________________________________
List hosting provided by Directions Magazine | www.directionsmag.com |
To unsubscribe, send e-mail to [EMAIL PROTECTED] and
put "unsubscribe MapInfo-L" in the message body.

Reply via email to