Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Clipper Application under Windows 7 performing Slow in Indexing / Accessing Dbf files from a Network Server
1,435 views
Skip to first unread message
swapan...@gmail.com
Aug 21, 2012, 12:01:55 PM8/21/12
to
Dear Group:
My Clipper Applications runs on a network. The EXE is located in each client's system and executed from there. The Dbf files are located on a shared drive of a Novell Server. The setup is:
Client side (20-25 users): Have Windows XP and Windows 98(a couple of them...) systems.
Server: Novell Server Netware5 running on Pentium PIII (yes PIII). This version of Novell Server perhaps won't run on modern configurations.
Network: All systems connected to the novell server netware5 via LAN setup.
The Issue:
May I clear it first that, the existing Clipper Apps. runs smoothly and in good speed, and smoothly sync with the novell server. The issue has come when a few Windows7 systems are introduced to the network. The Clipper apps. runs smoothly here in Windows7 and with screen adjustments its like a full screen - so no issues in real life situation.
The only issue is with the SPEED. Indexing takes lot of time, file accessing/opening is taking lot of time - which gives a feeling that the concerned Clipper Application is running quite slow in this environment. And in low config. systems with Win98 it has become deadly slow with respect to file indexing and opening of dbf files.
May I also let you know that when I've kept the data and index files on the local drive of Windows7 system - then the speed is quite fast (these Windows7 are with decent config. with memory of 2GB RAM) but as soon as I redirect the dbf & index path to Novell Server it becomes very slow.
But the same application when ported to Harbour - the Harbour ver. EXE does the indexing very fast (even faster then my original Clipper App under WinXP), thus loading of the Apps. not slow even on Win7 with Harbour versions..
I want to RESOLVE the issue under Clipper platform itself. Sorry for such long post, but I wanted to give the exact feedback under all the circumstances so far I have noticed.
Look forward to active participation from the group members here.
Thanks & Regards,
Swapan Das
My Clipper Applications runs on a network. The EXE is located in each client's system and executed from there. The Dbf files are located on a shared drive of a Novell Server. The setup is:
Client side (20-25 users): Have Windows XP and Windows 98(a couple of them...) systems.
Server: Novell Server Netware5 running on Pentium PIII (yes PIII). This version of Novell Server perhaps won't run on modern configurations.
Network: All systems connected to the novell server netware5 via LAN setup.
The Issue:
May I clear it first that, the existing Clipper Apps. runs smoothly and in good speed, and smoothly sync with the novell server. The issue has come when a few Windows7 systems are introduced to the network. The Clipper apps. runs smoothly here in Windows7 and with screen adjustments its like a full screen - so no issues in real life situation.
The only issue is with the SPEED. Indexing takes lot of time, file accessing/opening is taking lot of time - which gives a feeling that the concerned Clipper Application is running quite slow in this environment. And in low config. systems with Win98 it has become deadly slow with respect to file indexing and opening of dbf files.
May I also let you know that when I've kept the data and index files on the local drive of Windows7 system - then the speed is quite fast (these Windows7 are with decent config. with memory of 2GB RAM) but as soon as I redirect the dbf & index path to Novell Server it becomes very slow.
But the same application when ported to Harbour - the Harbour ver. EXE does the indexing very fast (even faster then my original Clipper App under WinXP), thus loading of the Apps. not slow even on Win7 with Harbour versions..
I want to RESOLVE the issue under Clipper platform itself. Sorry for such long post, but I wanted to give the exact feedback under all the circumstances so far I have noticed.
Look forward to active participation from the group members here.
Thanks & Regards,
Swapan Das
cal
Aug 21, 2012, 12:51:27 PM8/21/12
to
On Tue, 21 Aug 2012 09:01:55 -0700 (PDT), swapan...@gmail.com
wrote:
Is your LAN Ethernet? The reason that I ask is that indexing
operations place very heavy throughput workloads on the network
infrastructure, cabling, NICs and server. Running an app typically
places much lower demands. Maybe a switch or router is becoming old
and tiired, or a NIC is causing problems, maybe eve the NIC in the
server.
Just my first thoughts and a place to begin looking.
Cal
wrote:
operations place very heavy throughput workloads on the network
infrastructure, cabling, NICs and server. Running an app typically
places much lower demands. Maybe a switch or router is becoming old
and tiired, or a NIC is causing problems, maybe eve the NIC in the
server.
Just my first thoughts and a place to begin looking.
Cal
cal
Aug 21, 2012, 12:56:23 PM8/21/12
to
performed over the netwok by a Win 7 workstation?
Cal
swapan...@gmail.com
Aug 21, 2012, 1:51:06 PM8/21/12
to
On Tuesday, August 21, 2012 10:26:23 PM UTC+5:30, cal wrote:
> After further thinking... do the indexing operatiosn run slowly when
> performed over the netwok by a Win 7 workstation?
> Cal
Dear Cal..........
> After further thinking... do the indexing operatiosn run slowly when
> performed over the netwok by a Win 7 workstation?
> Cal
Thank you so much for paying attention to this thread....
The issue is only when I use Windows 7 workstations, otherwise its quite Ok with Win XP or Win 98.
Yes, Win7 workstation takes huge time in indexing files and loading all the dbf files from the Novell Server (this I'm doing as soon as exe is executed, after all the index files and dbfs are open...main menu comes up..)
But, when I test this as a STANDALONE application - i.e keeping the dbf & index files in the local drive (d: drive in my case) of my Win 7 workstation and run the application - ITS QUITE FAST in building the index files and opening of dbfs...
And as I've told in my initial post, if I run a harbour compiled (using MingW) EXE of the same application in the same setup - ITS INDEXES & OPENS DBF FILES EVEN FASTER then my original current setup (clipper exe under Win XP workstations)
[PS:BTW, I do use SET DELETED ON at the top of my application (house keeping commands) before file accessing & indexing them. And with index currently I don't use any clause like !DELETED.....]
Regards,
Swapan
swapan...@gmail.com
Aug 21, 2012, 2:00:41 PM8/21/12
to
Thanks a lot for responding....
Yes, the setup is more or less like that only you've assumed. But please note under my current network setup the Clipper Applications are not facing this issue of slow indexing and slow opening of dbf files. Its only when I do this under Win 7 system.
I was initially very happy when found that under Windows 7, we can still connect to Novell Server Netware 5 (such an old Server ver.). But this issue can become a big issue if more workstations with Win 7 are incorporated in....
Any Novell Server user here?
Yes, the setup is more or less like that only you've assumed. But please note under my current network setup the Clipper Applications are not facing this issue of slow indexing and slow opening of dbf files. Its only when I do this under Win 7 system.
I was initially very happy when found that under Windows 7, we can still connect to Novell Server Netware 5 (such an old Server ver.). But this issue can become a big issue if more workstations with Win 7 are incorporated in....
Any Novell Server user here?
dlzc
Aug 21, 2012, 3:37:18 PM8/21/12
to
Dear Swapan Das:
On Tuesday, August 21, 2012 10:51:06 AM UTC-7, SWAPAN DAS wrote:
> On Tuesday, August 21, 2012 10:26:23 PM UTC+5:30, cal wrote:
>
> > After further thinking... do the indexing
> > operatiosn run slowly when performed over the
> > netwok by a Win 7 workstation?
>
> But, when I test this as a STANDALONE
> application - i.e keeping the dbf & index files
> in the local drive (d: drive in my case) of my
> Win 7 workstation and run the application - ITS
> QUITE FAST in building the index files and
> opening of dbfs...
How can you have the data centrally located, yet expect each new client session to form its own indexes? You'd save lots of overhead if you simply had the full set of indexes already formed, and everyone share those.
I know this is a bit like... "Doctor, it hurts when I do this. Well, don't do that!"
> And as I've told in my initial post, if I run
> a harbour compiled (using MingW) EXE of the
> same application in the same setup - ITS INDEXES
> & OPENS DBF FILES EVEN FASTER then my original
> current setup (clipper exe under Win XP
> workstations)
(x)Harbour are Windows console applications, so they do not run the NTVDM session that 16-bit MS-DOS applications require.
> [PS:BTW, I do use SET DELETED ON at the top of
> my application (house keeping commands) before
> file accessing & indexing them. And with index
> currently I don't use any clause like
> !DELETED.....]
Small penalty, and like you say, the Harbour version of the application runs better still. I'd recommend you just migrate to Harbour on WinXP machines too. Leave the Clipper app for Win98 machines only.
David A. Smith
On Tuesday, August 21, 2012 10:51:06 AM UTC-7, SWAPAN DAS wrote:
> On Tuesday, August 21, 2012 10:26:23 PM UTC+5:30, cal wrote:
>
> > After further thinking... do the indexing
> > operatiosn run slowly when performed over the
> > netwok by a Win 7 workstation?
>
> The issue is only when I use Windows 7
> workstations, otherwise its quite Ok with
> Win XP or Win 98.
>
> Yes, Win7 workstation takes huge time in
> indexing files and loading all the dbf files
> from the Novell Server (this I'm doing as
> soon as exe is executed, after all the index
> files and dbfs are open...main menu comes up..)
So you are running a 16-bit NTVDM session in Windows 7, and using Novell drivers to boot.
> workstations, otherwise its quite Ok with
> Win XP or Win 98.
>
> Yes, Win7 workstation takes huge time in
> indexing files and loading all the dbf files
> from the Novell Server (this I'm doing as
> soon as exe is executed, after all the index
> files and dbfs are open...main menu comes up..)
> But, when I test this as a STANDALONE
> application - i.e keeping the dbf & index files
> in the local drive (d: drive in my case) of my
> Win 7 workstation and run the application - ITS
> QUITE FAST in building the index files and
> opening of dbfs...
I know this is a bit like... "Doctor, it hurts when I do this. Well, don't do that!"
> And as I've told in my initial post, if I run
> a harbour compiled (using MingW) EXE of the
> same application in the same setup - ITS INDEXES
> & OPENS DBF FILES EVEN FASTER then my original
> current setup (clipper exe under Win XP
> workstations)
> [PS:BTW, I do use SET DELETED ON at the top of
> my application (house keeping commands) before
> file accessing & indexing them. And with index
> currently I don't use any clause like
> !DELETED.....]
David A. Smith
cal
Aug 21, 2012, 4:25:23 PM8/21/12
to
On Tue, 21 Aug 2012 10:51:06 -0700 (PDT), swapan...@gmail.com
wrote:
So it's the Win7 workstations that are slow opening files and
indexing, and not the XP and Win98 stations. When Win 7 stations are
running, do the WinXp stations slow down at the same time, or do they
go at good speed at the same time the Win 7s are snails?
The reason I ask is I'm wondering if the Win7 NIC driver software
might be having a compatibility issue with Netware. I see that the
Win7 stations are fast accessing data from their local HDD.
Is there a Windows Server that you could try them with?
Cal
wrote:
indexing, and not the XP and Win98 stations. When Win 7 stations are
running, do the WinXp stations slow down at the same time, or do they
go at good speed at the same time the Win 7s are snails?
The reason I ask is I'm wondering if the Win7 NIC driver software
might be having a compatibility issue with Netware. I see that the
Win7 stations are fast accessing data from their local HDD.
Is there a Windows Server that you could try them with?
Cal
SWAPAN DAS
Aug 22, 2012, 12:24:08 AM8/22/12
to
On Wednesday, August 22, 2012 1:55:23 AM UTC+5:30, cal wrote:
> So it's the Win7 workstations that are slow opening files and
> indexing, and not the XP and Win98 stations.
EXACTLY!
> So it's the Win7 workstations that are slow opening files and
> indexing, and not the XP and Win98 stations.
> When Win 7 stations are
> running, do the WinXp stations slow down at the same time, or do they
> go at good speed at the same time the Win 7s are snails?
> The reason I ask is I'm wondering if the Win7 NIC driver software
> might be having a compatibility issue with Netware.
> I see that the Win7 stations are fast accessing data from their local HDD.
>
>
> Is there a Windows Server that you could try them with?
THINKING TO USE ONE WIN 7 WORKSTATION AS SERVER FOR THIS TEST. WILL MAP ONE OF ITS DRIVE AND KEEP THE DBFS & INDEX FILES IN THE SIMILAR WAY AS ITS KEPT IN THE NOVELL SERVER SHARED DRIVE. AND WILL EXECUTE THE APPLICATION FROM ANOTHER WIN 7 WORKSTATION TREATING IT AS A CLIENT AND CONNECTING TO THE WIN 7 MAKESHIFT SERVER. CAL RIGHT? ANYTHING ELSE??
And yes many thanks for pursuing this issue.....
SWAPAN DAS
Aug 22, 2012, 1:02:55 AM8/22/12
to
On Wednesday, August 22, 2012 1:07:18 AM UTC+5:30, dlzc wrote:
>
> How can you have the data centrally located, yet expect each new client session to form its own indexes? You'd save lots of overhead if you simply had the full set of indexes already formed, and everyone share those.
>
Dear David, on normal basis our other main applications DON'T create index files every time from each clients. If index files are found they are shared by all the clients/workstations. The Dbfs & index files are kept on a single location with separate folders. All connects to the common dbfs and index files kept on the novell server.
>
> How can you have the data centrally located, yet expect each new client session to form its own indexes? You'd save lots of overhead if you simply had the full set of indexes already formed, and everyone share those.
>
But my this particular Application is created later on which have its own set of index files, though uses the common dbfs of the other major applications. The issue came when sometimes the reports from this application doesn't reflects the latest changes, and found to have discrepancy occasionally. And this is because entries/changes are made on the other applications, and INDEX FILES of this system doesn't gets updated.... So I thought to introduce a FORCED INDEXING each time (or at-least have the option to have Force indexing with Y/n option) to avoid this discrepancy.
I can SHIFT this indexing to local drive, but doubt if it helps in speed up....as accessing dbfs will be always from server only, and that part has to be fast.
> I know this is a bit like... "Doctor, it hurts when I do this. Well, don't do > that!"
>
> (x)Harbour are Windows console applications, so they do not run the NTVDM session that 16-bit MS-DOS applications require.
>
>
> > [PS:BTW, I do use SET DELETED ON at the top of
>
You may suggest any workaround for this.....
> and like you say, the Harbour version of the application runs >
> better still. I'd recommend you just migrate to Harbour on WinXP machines >
> too. Leave the Clipper app for Win98 machines only.
Yes, I do place the harbour built EXE on XP users systems and waiting for any illegal behaviour.
Since this particular said application is on-going project; it will be difficult to maintain both clipper and [x]harbour versions, when I commit programming modifications which are unsupported in Clipper 5.01.
[And yes, though the Harbour ver. of my Clipper App. runs on Win98 using unicows, but it has issues. - would be out of topic here]
And yes David, thanks a lot for your concern. I have found you always been very helpful in these our xbase forums. Really appreciate. Would again meet here or any other group as per the issue.
Regards,
Swapan
Stephen Quinn
Aug 22, 2012, 1:24:39 AM8/22/12
to
It may be the version of Novell Client your using on the Win7 machines.
Check past messages in this group for more info.
CYA
Steve
H Davis
Aug 22, 2012, 8:35:20 AM8/22/12
to
Dear Swapan Das
I have one Windows 7 workstation connecting to a Novell 6.5 server,
using Novell Client 2, SP2. I find that the database opening, accessing
databases, & running reports is slower with this machine, then the remainder
of the workstations, which are running XP. I am running Xharbour programs,
not clipper. I believe the problem is with the network communications, but I
have not had time to investigate.
This may apply
http://www.novell.com/support/kb/doc.php?id=7002232
Which also has a link to Microsoft KB Article ID 2675785
Harold
"SWAPAN DAS" wrote in message
news:4eb27dc3-302e-4c54...@googlegroups.com...
I have one Windows 7 workstation connecting to a Novell 6.5 server,
using Novell Client 2, SP2. I find that the database opening, accessing
databases, & running reports is slower with this machine, then the remainder
of the workstations, which are running XP. I am running Xharbour programs,
not clipper. I believe the problem is with the network communications, but I
have not had time to investigate.
This may apply
http://www.novell.com/support/kb/doc.php?id=7002232
Which also has a link to Microsoft KB Article ID 2675785
Harold
"SWAPAN DAS" wrote in message
news:4eb27dc3-302e-4c54...@googlegroups.com...
dlzc
Aug 22, 2012, 10:02:22 AM8/22/12
to
Dear Swapan Das:
On Tuesday, August 21, 2012 10:02:55 PM UTC-7, SWAPAN DAS wrote:
> On Wednesday, August 22, 2012 1:07:18 AM UTC+5:30, dlzc wrote:
>
> > How can you have the data centrally located, yet
> > expect each new client session to form its own
> > indexes? You'd save lots of overhead if you
> > simply had the full set of indexes already formed,
> > and everyone share those.
>
...
> And this is because entries/changes are made
> on the other applications, and INDEX FILES of
> this system doesn't gets updated.... So I
> thought to introduce a FORCED INDEXING each
> time (or at-least have the option to have Force
> indexing with Y/n option) to avoid this
> discrepancy.
It would be a pain, but if you close the dbfs and indexes on the "other applications" after changes, then reopen, the indexes will be reliable.
> I can SHIFT this indexing to local drive,
> but doubt if it helps in speed up....as
> accessing dbfs will be always from server
> only, and that part has to be fast.
I'd recommend trying it. At least you would know.
...
...
...
David A. Smith
On Tuesday, August 21, 2012 10:02:55 PM UTC-7, SWAPAN DAS wrote:
> On Wednesday, August 22, 2012 1:07:18 AM UTC+5:30, dlzc wrote:
>
> > How can you have the data centrally located, yet
> > expect each new client session to form its own
> > indexes? You'd save lots of overhead if you
> > simply had the full set of indexes already formed,
> > and everyone share those.
>
> But my this particular Application is created
> later on which have its own set of index files,
> though uses the common dbfs of the other major
> applications. The issue came when sometimes
> the reports from this application doesn't
> reflects the latest changes, and found to have
> discrepancy occasionally.
Yes, this is the "Windows decides what commit really means, and does it when it feels like it" problem. I think it lies in how Windows handled shared files, with a single "user account". Everyone that accesses a file, has the same permissions, and is the exact same user. So Windows then assumes this one-user-with-many-bodys knows what every body wants written to disk, and they have worked it out between themselves.
> later on which have its own set of index files,
> though uses the common dbfs of the other major
> applications. The issue came when sometimes
> the reports from this application doesn't
> reflects the latest changes, and found to have
> discrepancy occasionally.
> And this is because entries/changes are made
> on the other applications, and INDEX FILES of
> this system doesn't gets updated.... So I
> thought to introduce a FORCED INDEXING each
> time (or at-least have the option to have Force
> indexing with Y/n option) to avoid this
> discrepancy.
> I can SHIFT this indexing to local drive,
> but doubt if it helps in speed up....as
> accessing dbfs will be always from server
> only, and that part has to be fast.
...
> > > [PS:BTW, I do use SET DELETED ON at the top of
>
> > Small penalty,
>
> You may suggest any workaround for this.....
I don't think it is your problem in this case, AND I believe it is much faster to have the "not deleted" flag in the index.
>
> > Small penalty,
>
> You may suggest any workaround for this.....
...
> Since this particular said application is
> on-going project; it will be difficult to
> maintain both clipper and [x]harbour
> versions, when I commit programming
> modifications which are unsupported in
> Clipper 5.01.
If you can show the customer how even the WinXP machines are faster with Harbour, they can retire the Win98 machines. But you cannot show this, if you do not migrate en masse. Your efforts here can save you difficulty into the future.
> on-going project; it will be difficult to
> maintain both clipper and [x]harbour
> versions, when I commit programming
> modifications which are unsupported in
> Clipper 5.01.
...
> And yes David, thanks a lot for your concern.
> I have found you always been very helpful in
> these our xbase forums. Really appreciate.
> Would again meet here or any other group as
> per the issue.
Thank you. Rare enough I feel I can offer useful advice...
> I have found you always been very helpful in
> these our xbase forums. Really appreciate.
> Would again meet here or any other group as
> per the issue.
David A. Smith
Klas Engwall
Aug 22, 2012, 4:13:51 PM8/22/12
to
Hi David,
>> But my this particular Application is created
>> later on which have its own set of index files,
>> though uses the common dbfs of the other major
>> applications. The issue came when sometimes
>> the reports from this application doesn't
>> reflects the latest changes, and found to have
>> discrepancy occasionally.
>
> Yes, this is the "Windows decides what commit really means, and does it when it
> feels like it" problem. I think it lies in how Windows handled shared files,
> with a single "user account". Everyone that accesses a file, has the same
> permissions, and is the exact same user. So Windows then assumes this one-user-
> with-many-bodys knows what every body wants written to disk, and they have worked
> it out between themselves.
???
It rather sounds like two (or more) different applications using the
same set of dbf files but with different sets of index files.
Swapan, wouldn't this be a good time to update both (all) applications
to use all the index files and not just the application specific ones?
Regards,
Klas
--- Posted via news://freenews.netfront.net/ - Complaints to ne...@netfront.net ---
>> But my this particular Application is created
>> later on which have its own set of index files,
>> though uses the common dbfs of the other major
>> applications. The issue came when sometimes
>> the reports from this application doesn't
>> reflects the latest changes, and found to have
>> discrepancy occasionally.
>
> Yes, this is the "Windows decides what commit really means, and does it when it
> feels like it" problem. I think it lies in how Windows handled shared files,
> with a single "user account". Everyone that accesses a file, has the same
> permissions, and is the exact same user. So Windows then assumes this one-user-
> with-many-bodys knows what every body wants written to disk, and they have worked
> it out between themselves.
It rather sounds like two (or more) different applications using the
same set of dbf files but with different sets of index files.
Swapan, wouldn't this be a good time to update both (all) applications
to use all the index files and not just the application specific ones?
Regards,
Klas
--- Posted via news://freenews.netfront.net/ - Complaints to ne...@netfront.net ---
dlzc
Aug 22, 2012, 5:26:19 PM8/22/12
to
Dear Klas Engwall:
On Wednesday, August 22, 2012 1:13:51 PM UTC-7, Klas Engwall wrote:
>
>
> >> But my this particular Application is created
> >> later on which have its own set of index files,
> >> though uses the common dbfs of the other major
> >> applications. The issue came when sometimes
> >> the reports from this application doesn't
> >> reflects the latest changes, and found to have
> >> discrepancy occasionally.
^^^ not this last sentence Klas...
> > Yes, this is the "Windows decides what commit
> > really means, and does it when it feels like
> > it" problem. I think it lies in how Windows
> > handled shared files, with a single "user
> > account". Everyone that accesses a file, has
> > the same permissions, and is the exact same
> > user. So Windows then assumes this one-user-
> > with-many-bodys knows what every body wants
> > written to disk, and they have worked it out
> > between themselves.
>
> ???
With Windoze NT (and maybe before), commit() is essentially ignored, as a Micro$haft design decision. The only way to guarantee your buffers get written to disk *now*, is to close the files. Requiring you to reopen, and move all the various "fingers" to the right places in the files and indexes. And I don't think this problem is unique to Windoze.
> It rather sounds like two (or more) different
> applications using the same set of dbf files
> but with different sets of index files.
Doesn't have to be.
> Swapan, wouldn't this be a good time to update
> both (all) applications to use all the index
> files and not just the application specific
> ones?
Danged good idea, if the indexes "commit"ted too. Swapan is indicating that they do not.
Which is why Swapan implemented this voodoo programming operation of creating unique indexes on the server for each user.
David A. Smith
On Wednesday, August 22, 2012 1:13:51 PM UTC-7, Klas Engwall wrote:
>
>
> >> But my this particular Application is created
> >> later on which have its own set of index files,
> >> though uses the common dbfs of the other major
> >> applications. The issue came when sometimes
> >> the reports from this application doesn't
> >> reflects the latest changes, and found to have
> >> discrepancy occasionally.
> > Yes, this is the "Windows decides what commit
> > really means, and does it when it feels like
> > it" problem. I think it lies in how Windows
> > handled shared files, with a single "user
> > account". Everyone that accesses a file, has
> > the same permissions, and is the exact same
> > user. So Windows then assumes this one-user-
> > with-many-bodys knows what every body wants
> > written to disk, and they have worked it out
> > between themselves.
>
> ???
> It rather sounds like two (or more) different
> applications using the same set of dbf files
> but with different sets of index files.
> Swapan, wouldn't this be a good time to update
> both (all) applications to use all the index
> files and not just the application specific
> ones?
Which is why Swapan implemented this voodoo programming operation of creating unique indexes on the server for each user.
David A. Smith
SWAPAN DAS
Aug 23, 2012, 12:40:07 AM8/23/12
to
Thanks Steve for attending this issue...
Lets see....
Lets see....
Klas Engwall
Aug 23, 2012, 6:59:32 AM8/23/12
to
David,
> With Windoze NT (and maybe before), commit() is essentially ignored, as a
> Micro$haft design decision. The only way to guarantee your buffers get
> written to disk *now*, is to close the files. Requiring you to reopen,
> and move all the various "fingers" to the right places in the files and
> indexes. And I don't think this problem is unique to Windoze.
Have you ever used dbcommit() in a network environment and seen what
actually happens?
> With Windoze NT (and maybe before), commit() is essentially ignored, as a
> Micro$haft design decision. The only way to guarantee your buffers get
> written to disk *now*, is to close the files. Requiring you to reopen,
> and move all the various "fingers" to the right places in the files and
> indexes. And I don't think this problem is unique to Windoze.
actually happens?
AnthonyL
Aug 23, 2012, 7:05:43 AM8/23/12
to
On Tue, 21 Aug 2012 11:00:41 -0700 (PDT), swapan...@gmail.com
wrote:
There is a dedicated news server for Novell issues at
support-forums.novell.com, probably also available via web browser.
There are some very knowledgeable people over there and in particular
this sort of question is asked a lot on
novell.support.netware.client.winnt-2x-xp
Good luck.
--
AnthonyL
wrote:
support-forums.novell.com, probably also available via web browser.
There are some very knowledgeable people over there and in particular
this sort of question is asked a lot on
novell.support.netware.client.winnt-2x-xp
Good luck.
--
AnthonyL
dlzc
Aug 23, 2012, 10:04:49 AM8/23/12
to
Dear Klas Engwall:
On Thursday, August 23, 2012 3:59:32 AM UTC-7, Klas Engwall wrote:
>
> > With Windoze NT (and maybe before), commit()
> > is essentially ignored, as a Micro$haft design
> > decision. The only way to guarantee your
> > buffers get written to disk *now*, is to close
> > the files. Requiring you to reopen, and move
> > all the various "fingers" to the right places
> > in the files and indexes. And I don't think
> > this problem is unique to Windoze.
>
> Have you ever used dbcommit() in a network
> environment and seen what actually happens?
With Clipper, running behind NTVDM, yes. Nothing reliable long term, as Swapan describes. I figure the client computers that are running WinXP, and Clipper code are the problem. The sooner he migrates them to the Harbour version, the better for him.
But he still needs to revisit this "personal index" design decision, so that everyone uses the same set of indexes. Will be much faster all around, if there are more than a few thousand records involved.
David A. Smith
On Thursday, August 23, 2012 3:59:32 AM UTC-7, Klas Engwall wrote:
>
> > With Windoze NT (and maybe before), commit()
> > is essentially ignored, as a Micro$haft design
> > decision. The only way to guarantee your
> > buffers get written to disk *now*, is to close
> > the files. Requiring you to reopen, and move
> > all the various "fingers" to the right places
> > in the files and indexes. And I don't think
> > this problem is unique to Windoze.
>
> Have you ever used dbcommit() in a network
> environment and seen what actually happens?
But he still needs to revisit this "personal index" design decision, so that everyone uses the same set of indexes. Will be much faster all around, if there are more than a few thousand records involved.
David A. Smith
SWAPAN DAS
Aug 23, 2012, 11:47:55 AM8/23/12
to
On Thursday, August 23, 2012 4:35:43 PM UTC+5:30, AnthonyL wrote:
> There is a dedicated news server for Novell issues at
> support-forums.novell.com, probably also available via web browser.
>
> There are some very knowledgeable people over there and in particular
> this sort of question is asked a lot on
> novell.support.netware.client.winnt-2x-xp
Thanks a lot AnthonyL for the links... yes could be really helpful. This particular group "novell.support.netware.client.winnt-2x-xp" doesn't shows much recent activities. But thanks for showing these avenues, will look into them.
> There is a dedicated news server for Novell issues at
> support-forums.novell.com, probably also available via web browser.
>
> There are some very knowledgeable people over there and in particular
> this sort of question is asked a lot on
> novell.support.netware.client.winnt-2x-xp
SWAPAN DAS
Aug 23, 2012, 12:06:52 PM8/23/12
to
On Wednesday, August 22, 2012 6:05:20 PM UTC+5:30, H Davis wrote:
> This may apply
> http://www.novell.com/support/kb/doc.php?id=7002232
> Which also has a link to Microsoft KB Article ID 2675785
>
> Harold
Dear Harold Davis:
> This may apply
> http://www.novell.com/support/kb/doc.php?id=7002232
> Which also has a link to Microsoft KB Article ID 2675785
>
> Harold
Thanks a lot for confirming that you TOO have faced/facing this issue. A "relief " that the issue is a bit "general" and not confined to me. Yesterday while googling did found this "supposed to solution" somewhere, but didn't applied because the forum member was not particularly addressing the slow opening of the dbf files.
In my case I have around 20 Win XP workstations, 2-3 Win98 workstations and couple of Windows 7 workstations connecting to a Novell 5 Netware server.
For Win7 workstations, using Novell Client 2, SP1. Was thinking for an update, but you are already running the updated ver. Novell Client 2 SP2 and still the issue prevails. So, today I didn't updated Novell Client for had a go for "Windows HotFix" solution as the link given by you:http://www.novell.com/support/kb/doc.php?id=7002232
I did all the things as mentioned in the above link. But for me the STATUS remains same .."SLOW ACCESS". If in the coming days you apply this hotfix, let me know/update here your results.
Thanks 1ce again for your much needed feedback...
Regards,
Swapan, India
SWAPAN DAS
Aug 23, 2012, 1:16:57 PM8/23/12
to
On Thursday, August 23, 2012 7:34:49 PM UTC+5:30, dlzc wrote:
> With Clipper, running behind NTVDM, yes. Nothing reliable long term, as Swapan describes. I figure the client computers that are running WinXP, and Clipper code are the problem. The sooner he migrates them to the Harbour version, the better for him.
>
> But he still needs to revisit this "personal index" design decision, so that everyone uses the same set of indexes. Will be much faster all around, if there are more than a few thousand records involved.
>
> David A. Smith
Dear Klas Engwall & David:
> With Clipper, running behind NTVDM, yes. Nothing reliable long term, as Swapan describes. I figure the client computers that are running WinXP, and Clipper code are the problem. The sooner he migrates them to the Harbour version, the better for him.
>
> But he still needs to revisit this "personal index" design decision, so that everyone uses the same set of indexes. Will be much faster all around, if there are more than a few thousand records involved.
>
> David A. Smith
First let me thank you both of you for attending this thread and esp. attending the "weak forte" of my Clipper application - "opening dbfs & indexing them over the network setup". I would like both of you to join to a new thread regarding this issue. Will soon open such a thread. Though would love to discuss here only, but in future any new reader referring to this thread for the 1st time may find a few posts "drifting" from the main issue of this thread.
The status as of now is that I didn't found any solution.
The only solution/workaround working for me is:
Switch/convert this Clipper Application to Harbour (or xHarbour, though not tested on xHarbour so far...)
Harbour compiled version has no issues, running much much faster then even the Clipper application on WinXP workstations connecting to Novell Server Netware 5.
Harbour ver. is opening the dbfs & creating indexes on both Win7 and WinXP with almost identical speed.
Regards,
Swapan
SWAPAN DAS
Aug 23, 2012, 1:22:48 PM8/23/12
to
On Wednesday, August 22, 2012 1:55:23 AM UTC+5:30, cal wrote:
> Is there a Windows Server that you could try them with?
> Cal
Sorry Cal, didn't had enough time so far to create such a setup and "test" this issue on such a setup. Whenever I'll do it, will update here.
> Cal
Regards,
Swapan
AnthonyL
Aug 24, 2012, 9:46:42 AM8/24/12
to
--
AnthonyL
SWAPAN DAS
Aug 24, 2012, 1:38:10 PM8/24/12
to
On Friday, August 24, 2012 7:16:42 PM UTC+5:30, AnthonyL wrote:
>group "novell.support.netware.client.winnt-2x-xp" doesn't shows much recent >activities. But thanks for showing these avenues, will look into them.
>
> It benefits from quality rather than quantity :)
>
> AnthonyL
>group "novell.support.netware.client.winnt-2x-xp" doesn't shows much recent >activities. But thanks for showing these avenues, will look into them.
>
> It benefits from quality rather than quantity :)
>
Dear AnthonyL:
I've posted my this issue to your mentioned group - "novell.support.netware.client.winnt-2x-xp"
Hope some1 will look into it....
Regards,
Swapan
AnthonyL
Aug 25, 2012, 7:18:06 AM8/25/12
to
support-forums.novell.com
Did you post it through google groups? That does look pretty empty? I
never use google groups but always go via the NNTP server above. If
you prefer web based then work your way to
http://forums.novell.com/forums/novell-product-discussions/file-networking-services/open-enterprise-server/oes-platform-independent/oes-client-windows/
Best then to create yourself a login otherwise I think you get
captcha's for almost everything (probably to stop google groups
access!!)
--
AnthonyL
SWAPAN DAS
Aug 26, 2012, 2:14:12 AM8/26/12
to
On Saturday, August 25, 2012 4:48:06 PM UTC+5:30, AnthonyL wrote:
> On Fri, 24 Aug 2012 10:38:10 -0700 (PDT), SWAPAN DAS
> On Fri, 24 Aug 2012 10:38:10 -0700 (PDT), SWAPAN DAS
> mmm - it's not showing up on the News Server at
>
> support-forums.novell.com
>
>
>
> Did you post it through google groups? That does look pretty empty? I
> never use google groups but always go via the NNTP server above. If
> you prefer web based then work your way to
Yes, I posted in the Google group. Perhaps there's less visits now, and people are more into the Novell forum for issues related with Novell.
>
> support-forums.novell.com
>
>
>
> Did you post it through google groups? That does look pretty empty? I
> never use google groups but always go via the NNTP server above. If
> you prefer web based then work your way to
Now I've posted, in the Novell forum, please do check again at the Novell forum link mentioned by you.
The link to my post is:
http://forums.novell.com/novell-product-discussions/file-networking-services/open-enterprise-server/oes-platform-independent/oes-client-windows/459320-slow-indexing-accessing-dbf-files-server-under-win7.html
Regards,
Swapan
Stephen Quinn
Aug 26, 2012, 6:03:18 AM8/26/12
to
Swapan
> Yes, I posted in the Google group.
Waste of time in this instance IMO.
> Perhaps there's less visits now, and people are more into the Novell forum
> for issues related with Novell.
Novell is a private forum and more than likely don't d/l posts made on
public forums (nntp, etc...), whereas Google will d/l posts from private
forums IF they can.
As far as most private forums go - it's one way traffic.
Eg
Post nntp - stays in nntp and google
Post private - stays private and might go public and/or google
CYA
Steve
> Yes, I posted in the Google group.
> Perhaps there's less visits now, and people are more into the Novell forum
> for issues related with Novell.
public forums (nntp, etc...), whereas Google will d/l posts from private
forums IF they can.
As far as most private forums go - it's one way traffic.
Eg
Post nntp - stays in nntp and google
Post private - stays private and might go public and/or google
CYA
Steve
AnthonyL
Aug 26, 2012, 6:07:04 AM8/26/12
to
at the time it took. Hopefully you'll get some responses, remember it
is summer holidays and currently weekend.
--
AnthonyL
SWAPAN DAS
Aug 26, 2012, 3:05:58 PM8/26/12
to
On Sunday, 26 August 2012 15:33:18 UTC+5:30, Stephen Quinn wrote:
> > Yes, I posted in the Google group.
> Waste of time in this instance IMO.
>
> > Yes, I posted in the Google group.
> Waste of time in this instance IMO.
>
> Novell is a private forum and more than likely don't d/l posts made on
> public forums (nntp, etc...), whereas Google will d/l posts from private
> forums IF they can.
> As far as most private forums go - it's one way traffic.
> Eg
> Post nntp - stays in nntp and google
> Post private - stays private and might go public and/or google
> CYA
> Steve
Thanks Steve for the inputs. Lets see if my thread in the Novell forum receives a solution for it...
> public forums (nntp, etc...), whereas Google will d/l posts from private
> forums IF they can.
> As far as most private forums go - it's one way traffic.
> Eg
> Post nntp - stays in nntp and google
> Post private - stays private and might go public and/or google
> CYA
> Steve
Regards,
Swapan
0 new messages