Upgrade + and -

Just finished our q 3 year upgrade on Quickbooks.

I wish all of the upgrades would be this smooth. All of the file conversions went well, all of the mapping to electronic payments was intact, and our payroll update subscription was validated with no problem.

If QB had been this easy to upgrade in the past, I might have upgraded more often.

Terminal services is working well in the Pro version, even though it is not officially supported.

It appears to pay off if you wait and upgrade QB after all the early adopters slog through the first release or two. Since QB is in R3 already, it looks safe.

The boot time seems longer than ever. Whatever speed improvements have occurred in QB 2006 seem to entirely negated by the incredible file size bloat.

Here are some representative file sizes before and after conversion from QB2003 to QB 2006, all in KB.

Before After

1029 7280 7728 15728 21393 32756 35549 50824

We need to put the QB data file on a weight reduction diet.

*Watt
Reply to
*Watt
Loading thread data ...

Given the incrediable capacity of today's modern disk drives, the bump in file size is immaterial.

Why don't you stop feeding it data? Its not Intuit's fault if you like to spoil the program.

Reply to
Allan Martin

Allan,

When I was taught computer programming, there was a concept of tight & efficient code. It would run faster and not waste resources. Clearly Intuit doesn't have that as a value anymore.

The code & database being inefficient suggests to me sloppy programming.

The time being wasted is no longer billable CPU time, but rather my own personal time waiting for a 50mB file to load across a network .

Yes, an annoyance. But clearly Intuit could do better. My files are 40% bigger, and I am not getting 40% more information.

IMHO, any speed claims for QB 2006 are entirely misleading.

*Watt

Reply to
*Watt

When you were in computer programming, tight & efficient code was required. Things have changed.

For example, in an earlier version of our software we compacted dates down to 2 bytes to conserve disk space. In our current release, dates are carried as eight-byte characters. That means that dates no longer have to be converted from an internal representation in order to do comparisons or sorting, the programming is considerably more straightforward with an enormouse reduction in bug potential. Further, today's PCs can transfer data to RAM at 50 times the speed of just a few years ago. So even if processing time is doubled, you're still way ahead.

I can buy a 1GB stick of RAM cheaper today than I could buy a ten megabyte hard drive just a few years ago. Yep, things have changed and programming techniques have changed in response. Today, micro efficiency is counter-productive.

Here's another example: QB is up to, what, Update #3 for 2006? How long did it take to release three updates for QB 2003? I suggest the ability of the programmers at Intuit to respond to oddities has markedly diminished with the newer techniques.

As for waiting for a 50 MB file to load across a network, well, QB 2006 doesn't load the file. File access is done on the server; all that moves are the transactions, not the whole file.

A computer is only as fast as its slowest part. In your case, find the slowest part and soup it up. Hint: the slowest part is probably not the file size or the software.

Reply to
HeyBub

Reply to
Steve Scott

In the interest of fairness, there are a few applications where going the extra mile for efficiency makes sense. Real-time database updating (such as processing of millions of credit card transactions per hour), mission-critical processes involving health or safety, space missions, writing compilers, and maybe a few others.

But for ordinary commercial transactions? Nah.

Reply to
HeyBub

Reply to
Steve Scott

Oh I don't know here in the UK version 6 had a major glitch all the way to R11 - and even when you had installed R11 you still had to go back and correct the errors. Oddly enough I came across a datafile only a couple of months ago that I had to correct pre V6R11 glitches on - their accountants had just been working round them (for 5 or more years!!!)

Reply to
mmaapp

A couple updates on how our QB 2006 rollout is going.

We host our files on a Windows 2003 Server, and use a Windows 2000 server to connect to our network remotely.

Because QB 2006 needs to have a copy of QB installed on the server, (even if you don't ever run the program locally on the server) we went ahead and followed Intuit's instructions.

Interestingly, the setup program wouldn't launch on our Win 2003 server. I rebooted the server, and it still wouldn't install. We have terminal server running on the Win 2003 server box, but use it only for administrative tasks.

A quick check of Intuit's tech support showed that you need to launch setup from a special setup program in the Qbooks directory, not the one in the installation CD's root directory IF you are running terminal server.

What is a bit interesting is that installing on our Win 2000 terminal server DIDN'T require using the special version of the setup program.

All of the programs and files now seem to be playing together well.

The speed seems slower for launching the program, and the data files are now

40% larger. They load slower too. Once you are all loaded and running, program execution seems faster.

Thus if you just need to load QB for a quick deposit or check, you will be slowed down. If your life revolves around using QB all day, you will be faster.

Your mileage may vary.

*Watt

Reply to
*Watt

BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.