Implicit vs Explicit OPEN in the context of FROM

[Ernesto Herrera]

Yes, Peter, it did have "auto-open". And we can actually put it back as an OPTION (so that an OPEN X is done implicitly by every FROM X), but let me please explain first why we removed it.

In versions prior to 2.0.64, FROM X did an implicit OPEN X because it was a very cheap operation (it only created the in-memory namespace context for each table -- i.e., the corresponding J "locale").

Beginning with 2.0.64 we added the capability of having stored procedures associated with each table (what PostgreSQL calls "methods"), and they are, of course, loaded when the table is OPENed. Thus, the OPEN operation although not necessarily expensive, is no longer guaranteed cheap.

Furthermore, since 2.0.66 we've begun implementing the code for Transactions, and this involves the setting of a "transaction context" *when* the table is OPENed.

Nevertheless, if you guys find it very convenient to have implicit OPENs, then we can add the OPTION to allow that behavior.

Any thoughts?

2009/6/10 <interna...@rzb.at>

Hi Jorge,

I'm just wondering whether version 2.0.62 had an "auto-open" feature that was dropped with version 2.1.31 because the script I sent you worked fine with 2.0.62

Best regards
Peter

jorge.a...@vectornova.com Gesendet von: jorgeantoni...@gmail.com   05.06.2009 18:28

An peter...@rzb.at Kopie interna...@rzb.at, ern...@vectornova.com Thema Re: Strange VSQL error

There are two issues here:
1.- FROM requires the table to be already opened, so you may type:
  OPEN table
  FROM table
or, since OPEN returns its right argument:
  FROM OPEN table

The error message indicates that the table you were trying to use was
not opened:
  |Invalid argument (not an opened table): throw
  |       FROM'Person'


2.- We've introduced changes in the schemas during 2.1 beta
development. You might have an old version of the Police Schema.
The following error message obviously does not provide any clear information
  |domain error: jmfmap
  |   HS_jmf_~:(-2+IF64)    (3!:4)(0,SZI)fileread fullfn
We will work to make it more explicit

Please re-create the database as follows:
- Delete C:\VSTAR32\Police
- Execute C:\n\n32\hlp\tut\Police\build.bat, it may take about 5
minutes to finish, depending on your hardware
- Wait until the "Police database created." message appears.
- Try to run the commands again:
USE 'Police'
Tables''
FROM OPEN 'Person'
SELECT 'ALL'


On Fri, Jun 5, 2009 at 10:57 AM,  <peter...@rzb.at> wrote:
>
> Hi Jorge!
>
> A script that worked perfectly until before 2.1 patch 31 of the Win32
> version now fails. I used vsql and manually entered commands (marked blue)
> to reproduce the problem. Here it goes:
>
> VectorStar 2.1 WIN32 Release Candidate 1.31
>    USE 'Police'
>    Tables''
> ┌──────┬───────┬────────────┐
> │Schema│Table  │Column      │
> ├──────┼───────┼────────────┤
> │Police│Model  │ID          │
> │Police│Model  │Photo       │
> │Police│Person │Document    │
> │Police│Person │Fingerprint │
> │Police│Person │Firstname   │
> │Police│Person │Gender      │
> │Police│Person │ID          │
> │Police│Person │Lastname    │
> │Police│Person │Phone       │
> │Police│Person │Photo       │
> │Police│Person │VERSION     │
> │Police│Ticket │Amount      │
> │Police│Ticket │Date        │
> │Police│Ticket │Driver      │
> │Police│Ticket │ID          │
> │Police│Ticket │State       │
> │Police│Ticket │Vehicle     │
> │Police│Vehicle│Color       │
> │Police│Vehicle│ID          │
> │Police│Vehicle│Make        │
> │Police│Vehicle│Model       │
> │Police│Vehicle│Owner       │
> │Police│Vehicle│Plate       │
> │Police│Vehicle│Registration│
> │Police│Vehicle│Year        │
> └──────┴───────┴────────────┘
>    FROM 'Person'
> |Invalid argument (not an opened table): throw
> |       FROM'Person'
> # I don't understand the error
> # I then tried this, just for the heck of it:
>    OPEN'Person'
> |domain error: jmfmap
> |   HS_jmf_~:(-2+IF64)    (3!:4)(0,SZI)fileread fullfn
>
> Please help!
> Best regards
> Peter
>
>
> P.S.: Next week I will be in the office only on Wendesday, Markus is on
> holiday, so take your time
>
> This message and any attachment ("the Message") are confidential. If you
> have received the Message in error, please notify the sender immediately and
> delete the Message from your system, any use of the Message is forbidden.
> Correspondence via e-mail is primarily for information purposes. RZB neither
> makes nor accepts legally binding statements via e-mail unless otherwise
> agreed to the contrary.
> Information pursuant to § 14 Austrian Companies Code: Raiffeisen Zentralbank
> Oesterreich AG; Registered Office: Am Stadtpark 9, A-1030 Vienna; Company
> Register Number: FN 58882t at the Commercial Court of Vienna.
>



This message and any attachment ("the Message") are confidential. If you have received the Message in error, please notify the sender immediately and delete the Message from your system, any use of the Message is forbidden.
Correspondence via e-mail is primarily for information purposes. RZB neither makes nor accepts legally binding statements via e-mail unless otherwise agreed to the contrary.
Information pursuant to § 14 Austrian Companies Code: Raiffeisen Zentralbank Oesterreich AG; Registered Office: Am Stadtpark 9, A-1030 Vienna; Company Register Number: FN 58882t at the Commercial Court of Vienna.

[interna...@rzb.at]

Hi Ernesto,

Vectorstar is famous for being fast. As you explained, the new behaviour is in favour of this aspect. So I totally agree.
As far as I can see it, you will need to implement an implict open (or OPEN ALL) anyway for ANSI SQL compliance. So, if you find the time to make this feature available via an OPTION statement it would be convenient. But this is of lowest priority.

Best regards
Peter

ern...@vectornova.com Gesendet von: e.h.le...@gmail.com   11.06.2009 09:11 Bitte antworten an ern...@vectornova.com@inet

An interna...@rzb.at Kopie vecto...@googlegroups.com Thema Implicit vs Explicit OPEN in the context of FROM