We are evaluating QuickBooks 2008 Enterprise and I am concerned about (so
far) our inability to open a data file in multi-user mode by default, the
message that additional users recieve when they open a data file about
"multi-user" mode, and, most of all, the apparent constant need to start (or
re-start) the "Database Server" software on our network server (Windows
2003) even though the DB Service is started by default.
Can anyone tell me about their experience -- good or bad -- using QuickBooks
in a true multi-user enviornment?
Thanks
Rich
Hi..
I don't have the exact message and its not an error message. It is a
notification that the file has been opened in multi-user mode and info about
how to switch to single user mode.
Rich
Hi --
I will check this all out. What happens often currently is the user gets an
error message stating the path may be invalid and an error number "-6177,0"
When this happens I have to stop and restart the Database Server Manager and
re-scan the QuickBooks file.
Rich
Hi --
Does this mean I have to install QB on the server? I thought the deal with
the latest version is that you could run the QB database server on Linuc
which would not, of course, be able to run QuickBooks itself.
Also the article mentions the file scanning utiltiy.. QuickBooks 2006 Data
File Scanning Utility. Although we are using Enterprise version 2008 and
there does seem to be a file scanning portion of the server installed. Is
this what they are referring too? The issue I have with this utility is that
it seems to need to always be running, as when you stop and start it it does
not remember the file(s) that it scanned.
Rich
So, you're running a knock-off of a 40-year-old operating system designed by
a money-losing division of your local telephone company and enhanced by
geeks who think the DOS-Command line is not obtuse enough?
Oh well.
Anyway, Intuit, in an effort to expand their market to the Linux desktop
(which runs on fewer machines than DOS 3.*) and tired of the decibel level
from the loons, says their database server WILL run on Fedora 6 and SUSE
10.2 [the other 33 known Linux distributions are problematic]. You have to
download some patches, the installation instruction manual, a Public Key,
and have six fingers on your left hand. This, of course, add at least three
things that can go catastrophically wrong (nine if you count the fingers).
Me? I'd move the database to the most heavily-used workstation and let the
Loonix machine sit in the corner happily counting its toes.
That most heavily used workstation is likely a MAC or a Solaris box.
If you want a real world comparison of computer speeds running a real world
problem take a look at the top computers running SETI
http://setiathome.berkeley.edu/top_hosts.php
As you all know 95%+- of computers are Windoze of some kind or another. Doing a
real quick scan of the first 60 entires or so only about 50% are on Windoze.
Why? With over 305,000 active hosts in the project the sample size is way to big
to be a fluke.
http://boinc.netsoft-online.com/e107_plugins/boinc/bp.php?project=1
Speed is not the criteria. If it were, the SETI folk would be using some
NSA-type sooper-computer. Cost, availablility, ease of use, and other
factors are evidently more important. It's easier to use 100,000 monkeys
than one Shakespere.
Why? In my view, the lay folk who use Windows relegate searching for
intelligent life in their OFFICE as a higher priority.
Considering your list, though, I find, of the top 20, 14 Windows machines
are involved, 6 Darwins (nekkid Macs), and 2 Linux.
This adds up to 22 machines - possibly due to the contribution of the two
Linux boxes.
Maybe Mac and Windows machines are placing high because more of them
are status symbols decorating a desk or lab with no real work to do?
Also, for those who don't know, Darwin (the core of OS X) is derived
from Berkeley Unix, Windows (from NT on) is sort of new (as of 1993)
but heavily influenced by VMS and also includes some Berkeley Unix.
Computers are complex systems- it can take literally decades of work
to make them really solid, longer if the first priority is something
else (like making lots of money).
As to the Linux question asked by the OP:
I haven't done the database server (I run a very small network and
computer repair and consulting shop with no "mid-market" customers
yet), but it looks like it could work with some consulting time to
fill in the gaps I suspect will be there ("verified on Fedora 6"
makes me me think they aren't really serious- if it said 'verified
on Enterprise Linux 5.1' I would have more confidence).
As an open source consultant, I would take the project on, but not
recommend it as the first choice for anything immediately mission
critical.
Back to the point.
I had a similar issue. All Windows XP Pro on 3 machines. One machine
is a server Hosting the QB file.
Some of us at the office wanted to access remotely. The cheap (free)
solution was a VPN software called Hamachi from Log Me In (installed
on the three machines).
Symptom: One user logs in, the other can't. Random errors when trying
to log in (Abort errors, Multi-User issues)
Fact: An IP is assigned to the QB Database Manager (QBDMgr) depending
on which adapter requests the file first. Hamachi VPN assigns IP
5.x.x.x, my local router (DHCP) assigns 192.168.1.x
Problem 1: When a user logs in from a remote location, the QBDMgr
adopts an IP that looks like 5.x.x.x. The second user is in the
office, using the local router with a local IP like 192.168.1.x. These
two networks are not in the same subnet, they don't know each other,
thus the QBDMgr doesn't allow the local user to log in. This could
happen the other way around; early in the morning the user sitting in
the same room as the server logs in first, which means that the QBDMgr
will begin "serving" locally with the same IP as the server, say
192.168.1.2. Then the remote user will not be able to open the shared
database because he is 5.x.x.x.
Problem 2: Both users are in the office and the three computers are
running the VPN, meaning that all computers have two IPs one local and
one assigned by VPN. Depending on the routing table (Start -> Run ->
"cmd" enter, then type "route print") of each of the user's computer
it is possible that one computer would connect through locally through
the hub and the other through the VPN (a long way)
Diagnose: Route print your PC and check which adapter has priority:
Router or VPN? Then on the computer that has the QB file open, hit F2
and on the bottom of the screen check that the server is adequate
5.x.x.x or 192.168.1.x (in my case)
Solution: there are plenty, one is playing with metrics of the adapter
and routing tables. The other is:
1. Logoff all the users
2. One of the users should log in.
3. Hit F2 and check what IP is beeing used (5.x.x.x or 192.168.1.x)
4. Act accordingly... :-)
4.a If both users are local then you can shut off the Remote
service (Power Off Hamachi), logoff QB and logon as a multi-user
again.
4.b The user on the remote end should login first (this assigns a
5.x.x.x to the QB server), then you should make sure that you have
your VPN running and just log on as a multi-user to the same file.
4.b.I If you're still getting the error message and you're sure
it's because of the this issue, then you're going to have to play with
the routing table, that's another Google search.
Hope this helps.
Back to the point.
I had a similar issue. All Windows XP Pro on 3 machines. One machine
is a server Hosting the QB file.
Some of us at the office wanted to access remotely. The cheap (free)
solution was a VPN software called Hamachi from Log Me In (installed
on the three machines).
Symptom: One user logs in, the other can't. Random errors when trying
to log in (Abort errors, Multi-User issues)
Fact: An IP is assigned to the QB Database Manager (QBDMgr) depending
on which adapter requests the file first. Hamachi VPN assigns IP
5.x.x.x, my local router (DHCP) assigns 192.168.1.x
Problem 1: When a user logs in from a remote location, the QBDMgr
adopts an IP that looks like 5.x.x.x. The second user is in the
office, using the local router with a local IP like 192.168.1.x. These
two networks are not in the same subnet, they don't know each other,
thus the QBDMgr doesn't allow the local user to log in. This could
happen the other way around; early in the morning the user sitting in
the same room as the server logs in first, which means that the QBDMgr
will begin "serving" locally with the same IP as the server, say
192.168.1.2. Then the remote user will not be able to open the shared
database because he is 5.x.x.x.
Problem 2: Both users are in the office and the three computers are
running the VPN, meaning that all computers have two IPs one local and
one assigned by VPN. Depending on the routing table (Start -> Run ->
"cmd" enter, then type "route print") of each of the user's computer
it is possible that one computer would connect through locally through
the hub and the other through the VPN (a long way)
Diagnose: Route print your PC and check which adapter has priority:
Router or VPN? Then on the computer that has the QB file open, hit F2
and on the bottom of the screen check that the server is adequate
5.x.x.x or 192.168.1.x (in my case)
Solution: there are plenty, one is playing with metrics of the adapter
and routing tables. The other is:
1. Logoff all the users
2. One of the users should log in.
3. Hit F2 and check what IP is beeing used (5.x.x.x or 192.168.1.x)
4. Act accordingly... :-)
4.a If both users are local then you can shut off the Remote
service (Power Off Hamachi), logoff QB and logon as a multi-user
again.
4.b The user on the remote end should login first (this assigns a
5.x.x.x to the QB server), then you should make sure that you have
your VPN running and just log on as a multi-user to the same file.
4.b.I If you're still getting the error message and you're sure
it's because of the this issue, then you're going to have to play with
the routing table, that's another Google search.
Hope this helps.
Can't wait to impliment your QB unsupported use of Hamachi. The users at my
cleint sites have nothing better to do then to screw around with settings
instead of doing their jobs. Repeat after me, "Terminal Services" is
supported by Enterprize.
On Dec 18, 2:21 pm, snipped-for-privacy@gmail.com wrote:
There are a couple of companies that are actually licensed by Intuit
to host using terminal services - hosting Pro, Premier and
Enterprise.
www.cpaasp.com and www.rightnetworks.com are the ONLY two that can do
this legally
BeanSmart.com is a site by and for consumers of financial services and advice. We are not affiliated with any of the banks, financial services or software manufacturers discussed here.
All logos and trade names are the property of their respective owners.
Tax and financial advice you come across on this site is freely given by your peers and professionals on their own time and out of the kindness of their hearts. We can guarantee
neither accuracy of such advice nor its applicability for your situation. Simply put, you are fully responsible for the results of using information from this site in real life situations.