Thanks for the quick replies! CurtR - yes, the clients load the database app off the server. Click the database app shortcut on the client desktop, and it takes about 10 seconds for the app to *start* to load on the client, then another two minutes to finish. Server is in another building, about 500 feet away. I tried moving the entire database folder from server to a single client, ,and running the app at the client. Works fast as lightning that way. But even with app on the client, and the database files themselves on the server, it takes two or three minutes to save a new item into the server-based database. Paul - we've restarted the server several times with no difference. We sometimes even get "program not responding" on the client when trying to save a file. It's like the network is moving like molasses, and the more of the "multi-users" that are using Resourcemate, the slower it gets. Thanks again. Tom

0

Should also add ... I once moved the entire database app and files from the server to a workstation, then networked other clients to it using Windows Networking. No change at all. The other workstations could load ResourceMate and access the database files on that other workstation, but saving a file still took two or three minutes. So I moved everything back to the server, as the entire server is backed up to tape every midnight. Interesting to note: if only one user is accessing the server database files, from *any* workstation, the file save is fast - like just a few seconds. Tom

0

Is there running any antivirus software, that may scan the database each time. Databases nomally should be excluded from scanning by antivirus software. Paul

0

Paul - correct. Symantec runs on the server, but the entire ResourceMate folder is excluded. And I've disabled AVG antivirus on the workstations as a test. No change. Tom

0

Chances are the problem you're encountering is a network issue. yes, the clients load the database app off the server. Click the database app shortcut on the client desktop, and it takes about 10 seconds for the app to *start* to load on the client, then another two minutes to finish. Server is in another building, about 500 feet away. I tried moving the entire database folder from server to a single client, ,and running the app at the client. Works fast as lightning that way. When you moved the db onto a client PC, that made it available on the LAN. With your server in another building 500 feet away, well, it's now considered a MAN or at the very least, the server is in a 'remote site' or 'remote location' from the client PC's. So, the issue seems to be between the LAN (Client PC's) and the building where the server is located. How are the two sites connected? What equipment runs between them? What type of connection do you have between buildings (ie: fiber optic link, Cat5e etc)?

0

Is it only the ResourceMate, that is slow or is it also slow to copy files from or to the server. If only ResourceMate is slow, I would say that it's a specific problem of ResourceMate. So maybe ResourceMate Support is the best way to get it to work. Paul

0

Curt - the two buildings are connected simply by 5e cable. From the switch in my building, one 5e runs to the other building, I believe to another switch. Paul - copying a 250M folder across the network (WinXP Explorer) takes about the same time as saving a single new item in the database - 2 to 3 minutes. Note that the file/save procedure is quite fast when there's only one user of Resourcemate. Soon as a second user tries to save files to that datatbase, file/save turns to molasses. Each user has a different Windows server login and password. Tom

0

Silly question !!! Is your version of ResourceMate a multiuser version ?

0

Not so silly answer!!! Yep - it's a multiuser version, with five user licenses (of which we're using four). Here's another juicy tidbit: When I copied the entire app to a workstation, and actually linked the workstation directly to another WinXP workstation (i.e. not using the LAN, server, Win2003, etc.), the saves from one machine to another were nearly instantaneous. Tom

0

Yes, but that's only one workstation and only one user accessing the database. Paul

0

Curt - the two buildings are connected simply by 5e cable. From the switch in my building, one 5e runs to the other building, I believe to another switch How long is that run of Cat5e? If it's over 80 meters, then you could be dealing with attenuation problems. However, due to the fact that it works good when connecting with a single client, and no so well with multiple clients connected, I'm more inclined to think it's the database software itself. When you put the db on an XP client and connected from another, did you also test with multiple XP clients all connecting at the same time? If yes, what were the results? Did performance degrade with more users connected?

0

@Curt R If copying 250MB with good speed, attenuation couldn't be the problem. All in all I think, "it is a problem by the database itself". Paul

0

This may add a new facet: I've seen ResourceMate multiuser operate with this large database on a Win2000 network. The file/save operation is quite fast, always under 30 seconds, even with five simultaneous users. But my system is Win2003, and multiuser file/save is tediously slow. Is there some Win2000 server to 2003 server change that might cause this problem? Tom

0

I don't know. On Microsoft System you'll never know ! But maybe it's possible to let the database run in compatiblity mode for Windows 2000. Paul

0

Though it could be cabling issues which you need to get a low level electrical contractor out to test... I am wondering what the workstations point to for DNS. Is the server running DNS server and are the workstations DNS entry that servers ip? Any database logs you can review? Any event viewer logs with errors? Have you called the database support line and done some troubleshooting with them? What is the access speed of a pc in the same building as the server? Like perhaps you should hook one up as a test? Imagine the power if you knew how to internet search

0

". Timeouts, freezes, slow file save, etc." Start with event viewer and then look at a performance monitor log or test. I read it wrong and answer it wrong too. So get off my case you peanut.

0

A question/comment. Isn't 500 feet of CAT 5 exceeding the 100 meter (320 feet) limit of the cable segment? It may have worked when the cable was new, but deterioration or damage has increased losses that retries are inceasing the connect time.

0

These are great suggestions. I hadn't even remembered the event viewer; I'll be back at the museum next Tuesday and will: 1. Check event viewer on the several workstations. 2. Try the file/save from a workstation in the building where the server resides. Say - is there some utility I can run which will check my hardware setup for windows and/or IP service problems? Tom

0

Hey wizard-fred, that was kind of my point when I asked him about the distance between buildings. You can push up to the 100 meter (328 foot) length if you want, but experience has taught me you don't ever really want to exceed about 85 meters. You won't get anything with a 500' cable....except a lot of errors. While it may work good copying a 250 Mb file, that doesn't mean you're not having attenuation issues. Personally, I still think it's the db software since he states it works ok when only one client is connected but goes to pot when more than one are connected.

0

"Soon as a second user tries to save files to that datatbase, file/save turns to molasses." Resource management problem, probably memory. Multiuser programs like these usually create virtual servers for each connection to the database, each of which eats up memory. Sometimes these virtual servers simply grab too much memory by default (ie, "all available") leaving little or none for local processing, causing "timeouts, slow file saves, etc.". See if you can set a "SessionMaxMemoryValue" or something like that in the configuration and play with it. Could also be your TCP/IP properties aren't optimized. Playing with those is not for the faint of heart because while some can be changed via menu, others require an in-depth understanding of the registry. Google for Win2K server TCP/IP optimization guides and backup the registry on your server and clients BEFORE you try anything. As for your "****" problem with tracert, traceroute programs are essentially automatic PING generators. They send a number of PINGs to a remote station, which responds back with an ACK. Tracert measures the delay between PING and ACK over a DNS routing and counts the # of dropped PINGs to give connectivity statistics. If you get "****" instead of an IP address back your Win2k Server's is set to deny this information. You'll always get the IP Address of your own client because that's local and the first "hop" that tracert checks. You'll have to go into the Advanced TCP/IP configuration menu (WAY down in the Advanced TCP/IP configuration menu!) to change this.

0

Could any of you suggest a utility (and documentation) I can use on a WinXP workstation that might help diagnose any Windows Networking and/or TCPIP problems I may have with setup and/or hardware on my network? There used to be a dialup utility called NetMedic - but it's long gone. It showed "hangups" all along the TCPIP route. Thanks. Tom

0

Is it cabling or database? Real simple solution, as I suggested, hook up some pcs locally and access the database. Still slow? Talk to the database tech support. They have a problem. Though it could be you are running other apps/services on the server that are sucking up resources requrired by the db. This is simple enough to troubleshoot. Use msconfig to disable startup apps. If no problem then its the wire. Put a fiber link in between buildings. Whoever advised/installed cat5 at 500ft should find another line of business. nutmegct there is nothing in your post to indicate any issue with tcp/ip or a workstation network configuration. You would be wasting your time going down this path since you have not eliminated the obvious two sources of your issue. By tracert to the internet you are not testing to the db server. You added other elements to the test that invalidate it imho. A tracert to the server is a valid test if you are looking at narrowing down the issue with the db access. Server and workstation OS's are different enough that your test of the db on a xp box is also invalid imho. You need a real test of server and workstation access as suggested above by taking the wire out of the mix. Imagine the power if you knew how to internet search

0

Hey I need to know a few things. Are they all connected to a central switch? Can you get all the workstations to ping the server continuously? The command for that is ping -t x.x.x.x (Replace x.x.x.x with the server's ip). If you are losing pings, then you might need to check the switch. The problem is not the database itself, nor the lack of tcp/ip optimization.

0

Since NetMedic is not longer available maybe you can find something to help at Tucows. "http://www.tucows.com/Windows/IS-IT/NetworkAdministrationProtocols"

0