I have a customer who is using my app (D7 and DBISAM 3.30 in shared file
mode).  The data files are stored in a network share for multi-user
access.  But for some reason, when one user is running the program, as a
second user start it up, the application hangs at the open table
statement until the first user closes the application.

The app works fine as a multi-user program for hundreds of other
customers, so I believe there is something different about this
customer's particular environment, but I can't figure out what the
difference is.

Customers environment...

Workstation 1 - XP Pro SP2
Workstation 2 - Vista Business SP1
Server - Small business server 2003 SP2

Share permissions - there is a security group that has full control of
the folder and the contents.  the staff members who need access to the
application are members of this group.

It doesn't seem to matter which workstation starts the program, the
other hangs in this process...

for i := 0 to ComponentCount-1 do
  if (Components[i] is TDBISAMTable) then begin
    with TDBISAMTable(Components[i]) do begin
      sStopWords := TextIndexStopWords;
      Exclusive := False;
      ReadOnly := False;
      Open;
    end;
  end;

I've tried creating a special build of the program using DBISAM 4.25 and
 the same problem occurred.

Any suggestions as to what else I can look at?
--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com

Gordon


Looking at the code you've posted I can't see any reason for it, but I do have a memory (vague) of someone else (might even have been you) having a similar problem.

As you say, if the app is running in lots of other sites suspect a difference here, and the difference I would look at first is hardware. Is it two specific PCs that cause the problem or is it any two from a lot? If the former suspect wiring or network adapters.

Roy Lambert

Gordon,

<< Customers environment...

Workstation 1 - XP Pro SP2
Workstation 2 - Vista Business SP1
Server - Small business server 2003 SP2 >>

There may be an issue with Vista and XP operating on the same network in
relation to the fact that XP uses SMB and Vista uses SMB 2 for their
file-sharing protocols.  The server may be having issues telling the Vista
machine to break its exclusive op-locks, or vice-versa.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:C36B9566-3CC8-4478-BDB7-ADA630E33F9A@news.elevatesoft.com...
> Gordon,
>
> << Customers environment...
>
> Workstation 1 - XP Pro SP2
> Workstation 2 - Vista Business SP1
> Server - Small business server 2003 SP2 >>
>
> There may be an issue with Vista and XP operating on the same network in
> relation to the fact that XP uses SMB and Vista uses SMB 2 for their
> file-sharing protocols.  The server may be having issues telling the Vista
> machine to break its exclusive op-locks, or vice-versa.
>

For what it's worth, I use a combination of Vista and XP sharing files
(DBISAM 4) no problems.

Robert

Tim Young [Elevate Software] wrote:
>
> There may be an issue with Vista and XP operating on the same network in
> relation to the fact that XP uses SMB and Vista uses SMB 2 for their
> file-sharing protocols.  The server may be having issues telling the Vista
> machine to break its exclusive op-locks, or vice-versa.

So is there a work-around at all?

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com

Gordon,

<< So is there a work-around at all? >>

First of all, my comments were simply speculation, so don't take them as
gospel.

However, if there was an issue like this, it is all controlled well below
the level of DBISAM, so no, there is no workaround that we can provide and
whatever MS does with the SMB protocols for file/resource-sharing is
completely up to them.

--
Tim Young
Elevate Software
www.elevatesoft.com

One of our apps uses a server file share similar to yours - multiple users
accessing it.

Just to duplicate your scenario I ran our app on 2 workstations  - XP Pro
SP2  and Vista Business SP1 and it works just fine - both can open the
tables from windows server share at the same time. In our case we're using
Server 2003 SP2 Standard but to best of my knowledge the file sharing is
identical to SBS you are using.

So i would say it's not a DBISAM problem and definitely related to this
environment. I also don't think Vista has any significance - Server 2003
uses SMB 1.0 still so Vista would not be using SMB 2.0 in this case at all
but fall back to v1.  However to test - have you tried running 2 XP clients
and see if same problem happens  ?

Couple of things i'd check:
- make sure server drivers are up to date (assuming it's a real HP/Dell/IBM
type box that would have vendor drivers for IDE/SCSI)
- make sure your file share allows unlimited connections (there is an option
to limit concurrent connections in windows)
- make sure your users have both file system (folder and files) and share
permissions (make them both full for example)
- any chance you're running into a SBS license (CAL) limit ? I think SBS
enforces the licenses (not totally sure on this one)
- any chance AV/Anti-Spyware/IDS software interacting on server or client ?

- what does the server show in Shared Folders management utility (in
sessions and open files ) when the 2nd PC is hanging ?

- finally there is always Filemon utility
(http://technet.microsoft.com/en-us/sysinternals/bb896642.aspx) that has
helped me out in numerous times troubleshooting file syste missues - it
provides a really good view into what happens in lower levels but takes a
bit of knowledge to interpret

Raul



"Gordon Turner" <gordon@mycroftcomputing.com> wrote in message
news:614FDD0D-65F0-4DA2-918F-5AE257BAD0A2@news.elevatesoft.com...
>I have a customer who is using my app (D7 and DBISAM 3.30 in shared file
>mode).  The data files are stored in a network share for multi-user access.
>But for some reason, when one user is running the program, as a second user
>start it up, the application hangs at the open table statement until the
>first user closes the application.
>
> The app works fine as a multi-user program for hundreds of other
> customers, so I believe there is something different about this customer's
> particular environment, but I can't figure out what the difference is.
>
> Customers environment...
>
> Workstation 1 - XP Pro SP2
> Workstation 2 - Vista Business SP1
> Server - Small business server 2003 SP2
>
> Share permissions - there is a security group that has full control of the
> folder and the contents.  the staff members who need access to the
> application are members of this group.
>
> It doesn't seem to matter which workstation starts the program, the other
> hangs in this process...
>
> for i := 0 to ComponentCount-1 do
>   if (Components[i] is TDBISAMTable) then begin
>     with TDBISAMTable(Components[i]) do begin
>       sStopWords := TextIndexStopWords;
>       Exclusive := False;
>       ReadOnly := False;
>       Open;
>     end;
>   end;
>
> I've tried creating a special build of the program using DBISAM 4.25 and
> the same problem occurred.
>
> Any suggestions as to what else I can look at?
> --
> Gordon Turner
> Mycroft Computing
> http://www.mycroftcomputing.com

Raul wrote:
>
> So i would say it's not a DBISAM problem and definitely related to this
> environment. I also don't think Vista has any significance - Server 2003
> uses SMB 1.0 still so Vista would not be using SMB 2.0 in this case at
> all but fall back to v1.  However to test - have you tried running 2 XP
> clients and see if same problem happens  ?

Yes.  The customer tried two XP workstations and got the same result, so
I too am pretty sure it does not have anything to do with Vista.  (I
tried the same experiment here using Vista Home and had no problems either.)

>
> Couple of things i'd check:
> - make sure server drivers are up to date (assuming it's a real
> HP/Dell/IBM type box that would have vendor drivers for IDE/SCSI)

I'll have the customer check this.

> - make sure your file share allows unlimited connections (there is an
> option to limit concurrent connections in windows)

The customer says that the share allows unlimited connections.

> - make sure your users have both file system (folder and files) and
> share permissions (make them both full for example)

Full control has been granted at the share level.

> - any chance you're running into a SBS license (CAL) limit ? I think SBS
> enforces the licenses (not totally sure on this one)

I'll have the customer check this.

> - any chance AV/Anti-Spyware/IDS software interacting on server or client ?

I'm not sure what impact this might have.  How would this interact with
access to DBISAM files?

> - what does the server show in Shared Folders management utility (in
> sessions and open files ) when the 2nd PC is hanging ?

I didn't know about this utility, and am having problems locating it on
my own SBS.  How would I access it?

> - finally there is always Filemon utility
> (http://technet.microsoft.com/en-us/sysinternals/bb896642.aspx) that has
> helped me out in numerous times troubleshooting file syste missues - it
> provides a really good view into what happens in lower levels but takes
> a bit of knowledge to interpret

I'll check into this as well.  I've used other utilities of theirs
(since back before they were acquired by MS).

>> - make sure your users have both file system (folder and files) and
>> share permissions (make them both full for example)
>
> Full control has been granted at the share level.
>

This is probably not the issue (since 1 user is able to access) but just for
reference : share permissions and file system permissions are combined to be
most restrictive. Full access at share level + read-only at file system =
read-only as final permissions. So for example if the user does not have
Create permissions at file system level then they are not able to create the
LCK file (even if share permissions are  full). Easiest to verify is also
give them Full permissions at folder level (this will ensure that they have
full create/modify/delete permissions).

>> - any chance AV/Anti-Spyware/IDS software interacting on server or client
>> ?
>
> I'm not sure what impact this might have.  How would this interact with
> access to DBISAM files?
>

There have been all kind of weird AV related issues - in your case it's a
file based access so any other application (e.g. AV) temporarily locking any
of the files might cause problems (see for example
http://www.elevatesoft.com/bulletin_14.htm). Recommendation is to exclude
the DBISAM data files (preferrably your whole share folder) from any AV
scanning.


>> - what does the server show in Shared Folders management utility (in
>> sessions and open files ) when the 2nd PC is hanging ?
>
> I didn't know about this utility, and am having problems locating it on my
> own SBS.  How would I access it?

Easiest is to access the Computer Management console (right click on My
Computer and desktop and select Manage or start->run->compmgmt.msc).
navigate to Shared Folder area and Sessions and Open Files would show
current share access details.

Raul

Raul wrote:
>
> There have been all kind of weird AV related issues - in your case it's
> a file based access so any other application (e.g. AV) temporarily
> locking any of the files might cause problems (see for example
> http://www.elevatesoft.com/bulletin_14.htm). Recommendation is to
> exclude the DBISAM data files (preferrably your whole share folder) from
> any AV scanning.

I've run into this problem frequently when data files are stored on the
local workstation (creating temp files in the users "temp" folder and
getting 11010 errors) but I didn't think the problem would manifest
itself in the data folder, since both users can individually access the
data.

>
> Easiest is to access the Computer Management console (right click on My
> Computer and desktop and select Manage or start->run->compmgmt.msc).
> navigate to Shared Folder area and Sessions and Open Files would show
> current share access details.

Thanks.  That's really nice to know about.  Could save some future
headaches.

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com