bb.donnay-software.com

Roger,

This is an issue from 6 months ago, but with a little more information.

We have users upgrading their servers from 32-bit to 64-bit, usually 2003 server to either 2008,2011 or 2012. We install the newest alaska for these, so no issue on that.
However, there are some users that barely can work due to write errors or operating system errors on zap, pack and reindex (for exclusive work files), mostly in our accounting modules. This involves hundreds of programs. This has never been an issue with 2008 server, or the older 32-bit servers.
It appears to be restricted, for the most part, to 2011 small business server. One user has an issue with 2008, but since we use that here I doubt that is a server issue.
Have you (or anybody else) had any issues like this, or aware of such issues? We think its something to do with the timing between the work stations and the server. There are never errors if you run on the server, of if you connect remotely using terminal server/remote access and run the same menu items.
Thanks, and see you in October.

Fred
Omni

omni wrote:We have users upgrading their servers from 32-bit to 64-bit, usually 2003 server to either 2008,2011 or 2012. We install the newest alaska for these, so no issue on that.

Server 2003 use SMB1. Since Server 2008 SMB2 are default.
Xbase ( all Version ) DBF System is File based so it need to use SMBx in Network

omni wrote:... due to write errors or operating system errors on zap, pack and reindex (for exclusive work files)

are these local temp files ?
what about CLOSE and re-USE File ?
did you use full UNC-Path

omni wrote:This has never been an issue with 2008 server, or the older 32-bit servers.

hm ... what OS() does your Client Workstation have ?

Hi,

Is this installed: http://www.alaska-software.com/fixes/smb2/overview.shtm?

See also http://support.microsoft.com/kb/2618096/en.

hi,

for SMB1 look @ http://en.wikipedia.org/wiki/Server_Message_Block how "Level 2 OpLocks" work.

skiman wrote:Is this installed: http://www.alaska-software.com/fixes/smb2/overview.shtm?

these "Fix" just are 3 Registry Patch for SMB2

1.) Directory cache, by setting DirectoryCacheLifetime to ZERO.

2.) File Not Found cache, by setting FileNotFoundCacheLifetime to ZERO.

3.) File information cache, by setting FileInfoCacheLifetime to ZERO.

which will "disable" LOCAL Cache :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanworkstation\Parameters

skiman wrote:See also http://support.microsoft.com/kb/2618096/en.

hm ... KB2618096 ... have to do with SMB-Redirector (Mrxsmb20.sys) which "communicate" with Server.

Since Windows NT we are working with SMB1 on Windows OS(). i may happens that you never had Problem with SMB1 ( or did not recognize it ).
to connect a Network Drive or Printer in a "Intranet" you had use Lanmanager with "NET USE ..."
Lanmanger will use UDP Port 135 - 139 (on Server) to "communicate"

Since Vista we have SMB2. this is need while now "Internet" is a Part of OS()
to connect a Network Drive or Printer via "Internet" you have to use UNC-Path
SMB-Redirector (Mrxsmb20.sys) "talk" on Port 445 ( on Server )

when install Windows OS(), since Vista, SMB2 is default and Server will listen on Port 445.
if Client "talk" via UDP Port 135 - 139 to Server than in will "fall-back" to SMB1 Protocol.

Problem "on" Server like "Level 2 OpLocks" are still SMB1 but your ZAP, REINDEX, DBSORT etc. will use local TEMP / TMP too ...
when have read Wiki you will know that Server do send "Event" to Client when something have "change".
but Server only know Directory which are "shared" ... it does not know about your TEMP / TMP.

if your local "Cache" is different from what Server "know" -> Data "inconsistent"
using Alaska "Fix" will "disable" local "Cache"

it is like you got Tires for your Porsche Turbo but you can´t drive fast while your Tires burst over Speed 200Km/h
and your Mechanic told you to "disable" your Turbo so you can´t reach 200Km/h.

Hi guys,

Well, I did find out some information. It appears to relate strictly to the set up on that server, and probably 2008 to a certain extent. The clients (two of them) in both cases disabled any antivirus on the server folder where the users write files, turned off UAC (which by default is turned on for 2011 server) and increased memory.
Not sure which had the most impact, but it took care of the errors.

Fred
Omni