No, having a single database engine host the file results in a faster and more secure environment.
No, the data would be hosted by the first workstation to open the file.
No, having a single database engine host the file results in a faster and more secure environment.
No, the data would be hosted by the first workstation to open the file.
Really? Please, enlighten us.
The data file is on a NAS (network attached storage), and you have let's say 3 PCs logged in the data file and apparently one of them has to be hosting the data file.
What exactly does this hosting do?
If System 1 does the hosting and System 2 needs to do a report or enter a bill, how does that hosting come into play?
If System 1 is running other apps and is mostly busy doing various calculations will System 2's need to do a report interfere with System
1's resource load? Will System 2's report be completed slower because System 1 was busy doing something else in another app?Can System 1 shut down QB or shut off completely at any time afterwards or do all 3 systems have then to shut down and System 2 or
3 restart QB so they can now do the hosting?I'm not a database expert but the more I think about this the more it looks like it's a colossal stupidity which is completely unfitting to a multi-user small business bookkeeping program.
///
Systems 2,3, 4, ....... 15 make their requests to System 1. System 1 is the single gatekeeper. Ever hear the expession too many chiefs spoil the broth?
Welcome to the laws of physics. Hopefully the workstation hosting the data will be the most powerful system in the office and dedicated for that purpose. The Enterprise version now supports up to 15 users. Doubtful the machine hosting the data will be used to photo editing as well.
Assuming the file does not reside on system 1, I do not know if shutting down system 1 (the host) will result in a dynamic host change to another workstation. Probably not. Then again it is also inadvisable to shut down a machine where the data is physically located if others are using the file. This is just common sense. What is your point?
We are talking about a local install of Quickbooks not Quickbooks online or Google's database servers.
Well perhaps that is why you are not an expert. This is exactly how most higher end workgroup database engines work. All the players elect a team captain.
I would be interested to read your thoughts on QB2006, as it will be what we get in Australia sometime next year.
Go Allan, the database expert! Did you give your email to someone else?
A small business is more likely to have a few systems in a p2p setup rather than a dedicated server. For a program like Quickbooks and a data file from 50MB to even 250MB there is absolutely no need to have a server to handle multiple users.
The point is that if the data file is on a network drive and not another PC then whoever becomes the host has to leave their system on and cannot shut it down if needed. If this is true, and it looks like it is, it is more of the same stupidity that is the hallmark of Intuit.
And you are? LOL!
///
I was talking about an intallation with 15 users.
Well like I said I did not know if all users must shut down QB and then start up again so a new host can be assigned. I am assuming that the answer is yes and is similar to Microsoft's desktop version of SQL and Pervasive's Workgroup database engine.
To be honest I'm not even sure the data can reside on a network drive. Perhaps it can. I heard today that it can reside on a Novel server which for all practical purposes is the same as a network drive since the QB program can't run on a Novel Server.
How many tens of millions of workstations are on right now just because they are physically connected to a shared printer.
By the way, Intuit now uses a third party database engine just like most of the other accounting software vendors. It is not their engine anymore. You know all about their old database engine. You must have complained about it a hundred times in your prior posts. Now that they finally changed here you are finding fault once again. I think I am beginning to see a pattern here.
Not an expert but I certainly understand how having a one workstation act as the database host is not something to get all upset about.
15 users?? And they'd use Quickbooks? The Enterprise (same junk for $3,000 a pop) version maybe, but I thought even you was chasing people away if they dared say that they were using Quickbooks for anything more advanced than, say, printing one check per week.
I don't have much experience with these types of setups but I refuse to believe that other mainstream database applications out there make it necessary that in addition to the machine hosting the data file, be it a server or just a network attached storage device, one other PC has to remain running in order for other clients to be able to access and/or use the data file. There may be uses for this, I don't know, but it can't be mandatory, it's absurd.
What is this, a justification of why more than one system has to remain running in order for another system to access a data file that resides somewhere else? If it is, it's a good example of the moronic mentality that's on constant exhibit at Intuit.
The goal is to offer something simple, efficient and functional for small businesses. What they used before as a database was utter crap. What they use now has to be these things otherwise it doesn't matter if it is state of the art for a completely different purpose other than having a data file and allowing users to access it, enter bookkeeping transactions and making reports.
Up to now it looks like usability is again at the bottom of their priorities.
///
Now that the program uses an industry standard database the rules have changed.
Hosting does not mean physically having the data on the machine's hard drive. Hosting refers to coordinating access to the file.
For 99.9% of the users the machine where the data resides will also be the host. Therefore no problem and totally transparent to the users. The setup is so simple that even you can do it.
They mothballed QBE in Canada in June 2004. AND I thought it was limited to
10 users (2 5-user license packs)?
It was because it was selling pretty well, I guess.
Enterprise was what QB should be in terms of data structure and user permissions, and it was still missing some useful features for a small business.
Otherwise it was the eact same crap. Can you imagine 10 users having access to a 150MB file and 3 of them calculating a report? If they change anything trivial on it, like a header etc, the reports will have to recalculate from the start.
If that's not incompetence I don't know what is.
///
Does that mean you'll have to jump higher when you cheer?
Let's see how this will work out. I predict a flood of problems with this. Will you be here to help out with their tech support problems?
Considering Quickbooks can't sort, they must have brought in a lot of outside expert talent to do this database switch.
Cheer on!
///
Absolutely that is what I do for a living. Unfortunately I don't expect to generate many fees from this because Intuit spent over 3 years in development of this transition. They wanted to make sure it worked.
Why have you tested out 2006 yet? How do you know your sorting problem has not been resolved? Higher end database engine usually comes with all sorts of end user benefits.
OK, now you're scaring me. You can't be Allan the Intuit Cheerleader. You must have given your Usenet login info to someone else.
I have to make sure that all external apps built on the SDK of previous versions will continue to run, which is probably not the case.
At some point I'll get it and try it out but I don't have high expectations. Even with a new database structure I'm almost certain they have found a way to block certain fields from being shown on reports, like the Job field on a Vendor Open Bills report. Even the Vendor History new thing they added *cannot* be filtered by Job or show the Job of the open and/or paid Vendor Bills.
A new database design was a necessary step for improvement, but it looks like their brains have remained at the same level of incompetence.
///
SDK apps work OK with 2006. SDK apps don't read the QB file directly.
I don't understand.
Well now that they have an industry standard database custom reports can be designed using the de-facto industry standard Crystal Reports. The data will also be accessable via Access and Excel. It would not supprise me if third party vendors start designing special reporting tools just for QB.
Went to a large Intuit sponsored QB 2006 Accountant Edition seminar last week. During his presentation the instructor went out of his way to praise you and your data transfer product. You the man!
///
Otherwise it was the eact same crap. Can you imagine 10 users having access to a 150MB file and 3 of them calculating a report? If they change anything trivial on it, like a header etc, the reports will have to recalculate from the start.
If that's not incompetence I don't know what is.
///
Are you saying you have difficulty with the above sort of scenario? That sort of load is trivial in QB Enterprise. I have one client with 10 users on one datafile all day long - the file is now over 400MB and several of them run / mod reports throughout the day. No one has any difficulties accessing the data and response time is excellent. Of course, I know how to set up a server properly for this kind of thing but that's all straightforward, well documented info anyway.
In addtion it has been reported that the Enterprise version for 2006 will run from 2 to 5 times faster.
>
If you can point us to a resource with instructions on how to set up a simple peer to peer WinXP network (no server software) for getting maximum efficiency with Quickbooks I'm sure I and a lot of other people would appreciate the information.
In a p-t-p setup where small and large multi-MB copy from one system to another at about 70% network utilization (as measured in Window's Task Manager, however accurate that is) When Quickbooks is calculating a report with the data file on a network storage device, network utilization never goes over 9-10%.
It may be because QB is doing many requests for small bits of information when it's doing a report, I don't know, but I would expect it to be faster. Whatever the reason is, if the actual code of QB did not make it necessary to recalculate a report when a user changes a header or something else trivial like that this problem would be lessened significantly.
Thanks in advance.
///
Have something to add? Share your thoughts — no account required.
Ask the community — no account required