I'm trying to write a fairly simple operation to copy a table and am being thwarted by my ignorance of BASIC+'s dynamics. My program (below) always fails on accessing the backup. What am I doing wrong?

SUBROUTINE COPYTABLECHECK(VOID)

Declare Subroutine Set_Status, Copy_Table

Declare Function Get_Status

FILE='

FILE=TEST_TABLE"

FOOVAR=0

*TEST IF FILE EXISTS

OPEN FILE TO FOO THEN

Set_Status(0)

status="

Set_Status(0)

• ATTEMPT TO BACKUP TABLE

Copy_Table(FILE,'','',FILE:"_BKP",0,0,1,0,status)

• ACCESS BACKUP, FAILS HERE

Open FILE:"_BKP" TO BAR THEN

 CALL MSG("PROCEDURE SUCCESS!",'','','')

END ELSE

 CALL MSG("COULD NOT OPEN FILE BACKUP!",'','','')

END

END ELSE

CALL MSG('FILE DOES NOT EXIST',,,) END </QUOTE> —- === At 21 MAY 2008 05:36PM Warren Auyong wrote: === <QUOTE>Add a get_status call and see what error code it returns. </QUOTE> —- === At 21 MAY 2008 10:22PM Bruce Cameron wrote: === <QUOTE>Just a thought. Variable file might be coming back as from the copy_table routine? Try doing a debug and F10 (stepping) thru the code and see what they are. It may also be that the _BKP has a problem during the call and doesn't exist. Or remove all the file and replace with hardcoded values. Just and FYI, in your example saying File=" File=TEST_TABLE" You can just say File=TEST_TABLE" since there are no delimiters it is attribute and you can just reference it that way in the code. Good luck. </QUOTE> —- === At 22 MAY 2008 01:18AM Warren Auyong wrote: === <QUOTE>Ok, you need to insert an ATTACH_TABLE after the COPY_TABLE. If you are going to copy a number of tables you can put this outside the COPY_TABLE loop and just attach the volume (assuming all the files are in the same volume). </QUOTE> —- === At 22 MAY 2008 12:37PM Mat Kelly wrote: === <QUOTE>I've done that and now have the following. When attaching I get a FS404, I'm guessing it's because I already have the volume (though not this newly created table) attached. The copy_table operation seems to complete without a problem. When Attach_table is run, STATUS is set to 1 and STATUS_CODE to 'FS404|C:\PATHTODATA\RTP57*ALREADY\ATTACHED\DATAPATH|AREV32_1' Any clue where I'm going wrong? How do I get the newly created table attached? *REVISED CODE *———– Declare Subroutine Set_Status, Copy_Table Declare Function Get_Status FILE=' FILE=TEST_TABLE" Set_Status(0) *ATTEMPT TO BACKUP TABLE Copy_Table(FILE,,,FILE:"_BKP",0,0,1,0,status) if Get_Status(status_code) then Call Msg("Error on Copy",,,)

Return

End

Set_Status(0)

Attach_Table('C:\PATHTODATA\',FILE:"_BKP","","")

if Get_Status(status_code) then

Call Msg("Error on Attach: ":STATUS_CODE,"","","")

Return

End

*ACCESS BACKUP, FAILS HERE

Open FILE:"_BKP" TO BAR THEN

CALL MSG("PROCEDURE SUCCESS!",,,) END ELSE CALL MSG("COULD NOT OPEN FILE BACKUP!",,,)

END

END ELSE

CALL MSG('FILE DOES NOT EXIST',,,) END </QUOTE> —- === At 22 MAY 2008 02:09PM Warren Auyong wrote: === <QUOTE>I'm assuming the single quote instead of a double quote before the comma on you code example is just a typo here and on in your actual program. Make sure the volume name or path matches to what is previously attached as ATTACH_TABLE gets picky about that. This is what I tried - either of the attach_table calls work: SUBROUTINE COPYTABLECHECK(VOID) Declare Subroutine Set_Status, Copy_Table Declare Function Get_Status FILE=' FILE=CDS" FOOVAR=0 debug *TEST IF FILE EXISTS OPEN FILE TO FOO THEN Set_Status(0) status=" Set_Status(0) *ATTEMPT TO BACKUP TABLE Copy_Table(FILE,,,FILE:"_BKP",0,0,1,0,status) *call attach_table("C:\A32\ICARUS",file:"_BKP","","") call attach_table("C:\A32\ICARUS","","","") *ACCESS BACKUP, FAILS HERE Open FILE:"_BKP" TO BAR THEN CALL MSG("PROCEDURE SUCCESS!",,,)

END ELSE

CALL MSG("COULD NOT OPEN FILE BACKUP!",,,) END END ELSE CALL MSG('FILE DOES NOT EXIST',,,)

END

---

However I did find in v8.06 if I run the SSP again in SYSTEM MONITOR COPY_TABLE blows up with a VNA error but I can get the SSP to complete. If I shut down OI and restart COPY_TABLE runs again without error until I run it again without shutdown.

Warren, thanks for the help so far.

I examined your code and ran mine through a few different setups, still without success. The closest I seem to get is when I don't specify a table at all to be attached but rather specify just the directory (DATA\TB\ACCOUNT below), which I think isn't really attaching the table for lack of specification. In this case, opening the _BKP file still fails, i.e. it falls through to the ELSE of the OPEN command. Please take a look at the Copy_Table/Attach_Table configurations below and let me know where I might be going wrong.

Thanks!

Copy_Table(FILE,"DATA\TB\ACCOUNT",,FILE:"_BKP",0,0,1,0,status) Attach_Table("O:\DATA\TB\ACCOUNT",FILE:"_BKP","","") FS404|O:\DATA\TB\ACCOUNT|RTP57*DATA\TB\ACCOUNT|AREV32_1 Copy_Table(FILE,"O:\DATA\TB\ACCOUNT",,FILE:"_BKP",0,0,1,0,status)

Attach_Table("O:\DATA\TB\ACCOUNT",FILE:"_BKP","","")

FS259|TEST_TABLE|TEST_TABLE_BKP

Copy_Table(FILE,"",,FILE:"_BKP",0,0,1,0,status) Attach_Table("DATA\TB\ACCOUNT",FILE:"_BKP","","") SSP280|TEST_TABLE_BKP|DATA\TB\ACCOUNT|RTP57 Copy_Table(FILE,"",,FILE:"_BKP",0,0,1,0,status)

Attach_Table("DATA\TB\ACCOUNT","","","")

Fails when trying to open file after "successfully" attaching.

From the OI Help…

The Copy_Table command will copy a table only. It will not attach the table to the current session or add the table to the Database Definition. To attach the table refer to the Attach_Table command. To define the database refer to the Define_Database command

Mat, I'd suggest you make a copy of your data to a different folder than the original. Your code suggests the _BKP table will reside in same folder.

And, why not copy at a row level rather than table? Thus, you can have the _BKP table in the database definition. Takes longer to copy, but you can count the number of rows and keep statistics.

Dave

Dave, I'll take the row method into consideration.

It appears that the copy_table is working regardless of where the destination table is located. However, it's the subsequent attach_table failing that is supposedly preventing the OPEN command from completing. At Warren's suggestion I added the attach_table (below) with various parameters, but can't get it to complete.

What am I doing wrong?

Copy_Table(FILE,"DATA\TB\ACCOUNT",,FILE:"_BKP",0,0,1,0,status) Attach_Table("O:\DATA\TB\ACCOUNT",FILE:"_BKP","","") FS404|O:\DATA\TB\ACCOUNT|RTP57*DATA\TB\ACCOUNT|AREV32_1 Copy_Table(FILE,"O:\DATA\TB\ACCOUNT",,FILE:"_BKP",0,0,1,0,status)

Attach_Table("O:\DATA\TB\ACCOUNT",FILE:"_BKP","","")

FS259|TEST_TABLE|TEST_TABLE_BKP

Copy_Table(FILE,"",,FILE:"_BKP",0,0,1,0,status) Attach_Table("DATA\TB\ACCOUNT",FILE:"_BKP","","") SSP280|TEST_TABLE_BKP|DATA\TB\ACCOUNT|RTP57 Copy_Table(FILE,"",,FILE:"_BKP",0,0,1,0,status)

Attach_Table("DATA\TB\ACCOUNT","","","")

Fails when trying to open file after "successfully" attaching.

Sorry, Charles Steadham=Mat Kelly in this instance.

Do you have indexing on the source table? Relational indexes can cause a problem and should be removed from the target. There is an argument after "status" for this purpose.

Have you actually looked at a before and after of the target folder? Is it creating a set of REV files? Have you done a LISTVOLUME on the target folder?

From REVERROR.DAT

"FS404: The "%1%" volume has the same label ("%3%") as the "%2%" volume and cannot be attached."

DATA\TB\ACCOUNT is a different location from O:\DATA\TB\ACCOUNT it will be under your working directory for OI. O:\DATA\TB\ACCOUNT is on the root of O: unless O: is mapped so the root starts in your OI folder. If this is intentional then use the NAME_VOLUME subroutine to change the OI media/volume name of one or the other or both so the two are unique.

"FS259: The "%1%" table has relational indexes on it and the related table "%2%" is not available or attached for updating control information."

See Dave Harmacek's reply

"SSP280: Table "%1%" not found at "%2%", filing system "%3%"."

The target table does not exist because the copy failed due to existing relational index.

Copy_Table(FILE,"",,FILE:"_BKP",0,0,1,0,status) Attach_Table("DATA\TB\ACCOUNT","","","") Fails when trying to open file after "successfully" attaching. Again the _BKP file does not exist. ATTACHing a volume will add any previously unattached files. Failure here would be if the volume was unable to attach e.g. no REVMEDIA file, duplicate media name, unknown BFS. </QUOTE> —- === At 27 MAY 2008 09:19AM Dave Harmacek wrote: === <QUOTE>Yeah Warren! I wonder if Mat (Charles) did the error of copying a folder containing linear hash files? Mat, in this case the internal name of the folder, the "volume name", has been duplicated. Use the Namevolume to change it as Warren directs. Dave </QUOTE> —- === At 28 MAY 2008 11:53AM Mat Kelly wrote: === <QUOTE>Warren, I've taken your and Dave's advice into account, but still can't get over this hurdle. I'm trying the method that involves the code: Set_Status(0) Copy_Table(FILE,"DATA\TB\ACCOUNT",,FILE:"_BKP",0,0,1,0,STATUS,1)

if Get_Status(STATUS_CODE) then

call Msg("Error on Copy: ":STATUS_CODE,,,) Return end Set_Status(0) Attach_Table("DATA\TB\ACCOUNT",FILE:"_BKP","","") if Get_Status(STATUS_CODE) then call Msg("Error on Attach: ":STATUS_CODE,"","","") Return End …which always yields the SSP280 error, signifying that the copy failed due to existing relational index. The procedure gets past the copy, however, and even if I change the :"_BKP" to something previously non-existent like "_BKPA", the same error occurs. Additionally, in OI's database manager I can see the table when going to file ] add tables with listings such as: TEST_TABLE*MYAPPLICATIONNAME (the original table) TEST_TABLE_BKPA*MYAPPLICATIONNAME (the copied table) …but when trying to add them, I get the FS404 "volume has the same label" error. As you mentioned the original issue (SSP280) to be related to the relational indexes when they're supposedly not copied because of copy_table's last parameter, how do I go about attaching the copied table, which I presume was done so successfully due to copy_table not generating a STATUS_CODE? </QUOTE> —- === At 28 MAY 2008 01:38PM Dave Harmacek wrote: === <QUOTE>You said "When attaching I get a FS404, I'm guessing it's because I already have the volume (though not this newly created table) attached" This is not true. If the volume name is a duplicate, then no table in that volume can be attached. If that volume already has a table attached then you won't get that error message. Can't you tell if the backup folder has any tables attached in the Database Manager? Have you used the Database Manager to attach any other table in that backup folder? And, exactly what version of OI are you using? Examine the documentation for the Name_Volume subroutine. It tells you where the "Media Map" is stored and the significance of it being unique. Dave </QUOTE> —- === At 28 MAY 2008 02:20PM Mat Kelly wrote: === <QUOTE>Dave, I've revised the code a bit and am consistently getting the SSP280 error. Per the thread at http://www.revelation.com/o4wtrs/oecgi3.exe/O4W_DOMINO_HANDOFF?DESTN=O4W_RUN_FORM&INQID=WORKS_READ&KEY=4F2AEF966A5A93C48525745700574E0B&KEY1=4F2AEF966A5A93C48525745700574E0B I've tried it both w/ the path being mapped to a drive letter (O, which is also the root of my OI installed, i.e. OINSIGHT.exe and all of the support files are located there) with the same results. I also, for lack of a better solution, cleared all of the files out of the O:/DATA/TB/TEMP directory and did a run NAME_VOLUME 'O:\DATA\TB\TEMP','TEMP' and tried to execute the below program again with the same error. I'm using 8.0.5. Please let me know if you have any insight. *REVISED CODE *———– declare Function MSG2, Msg, Get_Status declare subroutine Copy_Table, Attach_Table, Set_Status FILE=' FILE=TEST_TABLE" Set_Status(0) *ATTEMPT TO BACKUP TABLE Copy_Table(FILE,"O:\DATA\TB\TEMP",,FILE:"_BKP",0,0,1,0,status,1)

if Get_Status(status_code) then

Call Msg("Error on Copy",,,'')

Return

End

Set_Status(0)

Attach_Table("O:\DATA\TB\TEMP",FILE:"_BKP","","")

if Get_Status(status_code) then

Call Msg("Error on Attach: ":STATUS_CODE,"","","")

Return

End

I don't see what the problem is, the code seems fine and works for me.

Are you using one of the file services like the Windows Service or the Universal Drivers?

If so you probably need a REVPARAM file in the target directory on the server.

Warren,

My WHO says I'm using All Networks Driver ver. 2.1. I tried installing UD 4 sometime back, but ran into some problems, as we currently have a production Arev31 application that sputtered after installing the new driver. Do you think that could be the issue?

I am running OEngineServer as a windows service, if that helps with diagnosing the problem. Please let me know your thoughts.

I'm stumped at this point. Your code works perfectly fine under v8.06 other than the COPY_TABLE VNA error I reported in the bug tracker.

I have OESocketServer running for OECGI2, All Networks Driver v2.1 with Windows 2000 Service 2.1 on the server, as well as Arev v3.12. I just tried your program with the target directory on the network/server as all my previous tests I had the target on my local hard drive. Ran without error to the network.

I take it the login you are using has create permissions on the target directory?

Mat,

I receive the same results as Warren when using your code. I too am on OI 8.0.6, however I am using the 4.0 driver (which according to Warren's tests using the 2.1 driver is a red herring).

What version of OI are you currently running? I can test on that version, once known.

Thanks,

Sean FitzSimons

Revelation Software

View this thread on the Works forum...