I inadvertently detached SYSTABLES and SYSVOLUMES and then saved the database. This meant those tables were no longer available when I logged back in (which surprised me…I figured they were always created on-the-fly).

Is there a way to use Attach_Table to add them back? I haven't found a way to do that.

BTW, this isn't a show-stopper for me. I was able to restore the DBT file but this exercise got me curious.

Don Bakke

SRP Computer Solutions, Inc.

which surprised me…I figured they were always created on-the-fly).

Surprised me too!

I did not know those tables could be detached. The program LOAD_SYSPROGDBT should be modified load them regardless of what the dbt indicates.

You might get away with calling attach table in "volume pointer on the fly" mode passing in path:@fm:bfs:@fm:control_info

location = "MEMORY_RESIDENT":@FM:"RTP50"

tables = "SYSVOLUMES":@fm:"SYSTABLES"



call attach_Table(location, tables, "GLOBAL")

BTW, The ability to use attach_Table to create effectively create a sysptr on the fly offers opportunities

For example, you can attach a volume with temporary volume mfs

mycontrolInfo = "" ; * information that the mfs needs

location = "myfolder":@FM:"MYMFS":@vm:"RTP57":@fm:mycontrolinfo

tables = ""



call attach_Table(location, tables, "")

if you are using the UD5, you can pass a semi-colon delimited revparam connectionstring on the fly

This should let you consume data from more than one UD

connectionString  = "ServerOnly=1;ServerName=172.16.21.101;TcpipPort=1234;NamedPipeName=None;UDVERSION=5" 

location = "myfolder":@FM:":"RTP57":@fm:mycontrolinfo

tables = ""



call attach_Table(location, tables, "")

Hi Don,

How did you manage to detach them? Detach_Table has a checklist of tables not to detach, and those two are the first in the list :)

Carl Pates

Hi Don,

How did you manage to detach them? Detach_Table has a checklist of tables not to detach, and those two are the first in the list :)

Carl Pates

Hi Carl - I was creating a POC BFS using our in-memory hashtable utility and I passed in "MEMORY_RESIDENT" as the location in Create_Volume (which I got from following the TEST_RTI_MEMBFS code). For the moment, this appears to do what was expected:

MemoryResidentBefore.png?dl=1

On a lark, I decided to save the database (even though I knew the table was virtual), and upon getting back in I saw my SYSTABLES and SYSVOLUMES tables were no longer attached:

MemoryResidentAfter.png?dl=1

So, I didn't detach them per se, but my actions created the same effect.

Don Bakke

SRP Computer Solutions, Inc.

Fair enough :)

Carl Pates

You might get away with calling attach table in "volume pointer on the fly" mode passing in path:@fm:bfs:@fm:control_info

location = "MEMORY_RESIDENT":@FM:"RTP50"

tables = "SYSVOLUMES":@fm:"SYSTABLES"



call attach_Table(location, tables, "GLOBAL")

FYI, this didn't seem to work. I received an FS130 error (BFS code not implemented ; code ; BFS name) when attempting this.

Don Bakke

SRP Computer Solutions, Inc.

View this thread on the Works forum...