Shadow not writing to server

[Alan Lucas]

Build 3033

For some unexplained reason certain child tables on the shadow workstation are no longer writing to the server.

Checking the tables on the workstation I see that half a dozen are not greyed out like the other 250 +. Checking on the properties of these tables I find some have no indexes while on the server they do.

Checking the data base information, under File in the control panel, displays these 6 tables, it's as if they think they are real tables and not shadows.

Tried many network optimizations, shadow refresh's but without success. Checked the development db and all tables seem ok.

Anybody else experienced this and fixed the problem?

Checked the forum but could not find and answer.

Finally this is happening on and all my network set ups.

Thanks

Alan

[CALocklin]

Re: Shadow not writing to server

If it's not grayed out, it's probably not shadowed. Check the file size to be sure. All shadowed dbf files have an actual file size of something like 187 bytes. They will show as 1K in a folder listing but you can see the 187 if you look at the properties for that specific file.

There should never be a CDX file with a shadowed table. If there is, the local workstation will use the local cdx which won't be in synch with the real data. In other words, IF you find a cdx file on a workstation and the cdx is attached to a shadowed table - remove the cdx immediately! (I have some tables on some workstations that are NOT shadowed even though the rest of the tables are shadowed so this is a possibility. In this case, a local cdx file would be normal.)

If you find that those tables really aren't shadowed, you may need to check the server tables for missing data that exists only in the workstation table. In this case, (a) have fun finding and fixing the errors and (b) I'd make a backup of those workstation files in another folder and keep it for at least a few months in case you find more missing data later. Then delete the files and rebuild the shadowed workstation from scratch.

[Alan Lucas]

Re: Shadow not writing to server

Thanks Cal,

Will check out your suggestions over the weekend and get back to you.

Alan

[Alan Lucas]

Re: Shadow not writing to server

Cal,

Found the 6 cdx files in the shadow, deleted them but when I open up the shadow from the workstation the .cdx files are recreated in the shadow. How do I stop this from happening?

Thanks

Alan

[Tom Cone Jr]

Re: Shadow not writing to server

Alan, more details would be helpful. Are the cdx's attached to the non-greyed out tables? Have you verified that the non-greyed out tables are local, instead of shadowed?

CDX's will be created by Alpha Five when needed for field rules or set definitions. If you're opening local tables, or a set comprised of local tables, Alpha is building indexes because they're needed in your field rules or set linkages.

Does your app deliberately use local tables for storage ?

-- tom

[CALocklin]

Re: Shadow not writing to server

I agree with Tom. And again, you can check the size of the .dbf files in your shadowed folder as a double check against the "blue vs. grayed out" status in the control panel - if they aren't 187 bytes then they aren't shadow files.

[Peter.Wayne]

Re: Shadow not writing to server

I seem to remember that Finian Lennon reported that there is a limit of about 250-300 tables and sets that a database can hold. I wonder if this is another instance of that limitation.

[CALocklin]

Re: Shadow not writing to server

Good point, Peter. It's a good thing somebody's memory still seems to be intact.

[Bob Arbuthnot]

Re: Shadow not writing to server

If the problem is indeed similar to Finian's post, I believe (but I can't find the thread), that was resolved by Ira Perlow and confirmed by Selwyn to be a limit not of the number of tables, but rather of the length of the directory and file names that Alpha strings together when creating a shadow database. Seems like Selwyn said it was 25K in Version 7 and that that limit has been removed for Version 8.

Alan can test this by creating his shadow in a short named folder (db?) in the root directory and see if the problem is resolved.

Bob Arbuthnot

[csda1]

Re: Shadow not writing to server

Hi Bob,

If the problem is indeed similar to Finian's post, I believe (but I can't find the thread), that was resolved by Ira Perlow and confirmed by Selwyn to be a limit not of the number of tables, but rather of the length of the directory and file names that Alpha strings together when creating a shadow database. Seems like Selwyn said it was 25K in Version 7 and that that limit has been removed for Version 8.

Alan can test this by creating his shadow in a short named folder (db?) in the root directory and see if the problem is resolved.

Here is a link to that thread;

http://msgboard.alphasoftware.com/al...ad.php?t=63813

[Alan Lucas]

Re: Shadow not writing to server

Problem identified and solved.

In one of my updates on the servers I had scripts in the autoexec that increased field sizes. Example of one of the scripts:

'PO Item unit cost fields
tablename="purchase order item"
original_sizes=<<%a%
price,n,8,2
invoice_price,n,8,2
%a%
new_sizes=<<%a%
price,n,10,3
invoice_price,n,10,3
%a%
a5_changefieldsize("purchase order item",original_sizes,new_sizes)

I never removed the scripts from the autoexec and it was these tables that were not being shadowed on the workstations.

I copied the shadow dbf's into another folder, deleted the shadow, installed a new update on the server (without the scripts in the autoexec), copied the shadow dbf's onto the server and ran a network optimization. Bingo, all tables in the shadow are now greyed out.

Tested with shadow refresh and all works correctly.


Alan

[CALocklin]

Re: Shadow not writing to server

I've done that on generic apps where some people update immediately and others may not update for many weeks. Note that I use my "datapath" variable that points to the actual data file. I'm pretty sure, now that you mention it, that I ran into a similar problem with this command when I did NOT use the "datapath". I now specify the "datapath" on all updates that would affect table structure and might be run on a shadowed folder.

FWIW: I also solved the problem of "does it need to be updated" by testing the field length first so the update would only run once. This isn't as critical here as it is when adding fields to tables. When adding fields to tables I use the a5_get_fieldnames() command and check the list for a name match.

Perhaps these would be another solution to your issue.

Heres my script for changing field length:

DIM datapath as C
IF a5.Get_Master_Path() = ""
   datapath = a5.Get_Path() + chr(92)
ELSE
   datapath = a5.Get_Master_Path() + chr(92)
END IF
tpc = table.open( datapath + "Clients.dbf" )
fld1 = tpc.field_get( "Def_agentf" )
fwid1 = fld1.width_get()
tpc.close()
'Change width of fields in Clients 04-30-05.
IF fwid1 <> 30
    Old_list = <<%list%
Def_agentf,C,20,0
%list%
    New_list = <<%list%
Def_agentf,C,30,0
%list%
    a5_changefieldsize( datapath + "Clients.dbf", old_list, new_list )
END IF

[Alan Lucas]

Re: Shadow not writing to server

Thank you Cal,

Understand the logic. This was the first time I needed to increase field sizes on an existing app. Will test your script.

Alan