Our company is a long term Act! User starting with v4. We are also using MAS500. We are now attempting to implement a company wide single database with remote users upgrading 24 Act! v6 database islands into a common v10 database. We originally started this process 1-1/2 years ago with v9. The nature of our company's e-mail correspondence with engineering firms cause our attachment file size to be rather large. The attachment file size of our main database is now 13.9 GB with only 9 of our 24 users transitioned over to the v10 main database.
here are the problems encountered so far
1. Act! won't back up an attachment file over 4 GB. We can over come this by backing up the attachment file separately.
2. Act! won't cut a remote database with an attachment file larger than 4 GB.
3. Act! Won't synch a remote database with an attachment file size over 4 GB.
It appears that the 4 GB attachment file size issue is a structural issue with ACT!
Is this something that can be fixed so that I can continue my implementation?
Sorry to jump in on this thread - but we also have problems with database back up and creating/synching remote databases due to large Attachments folder.
(I'm just realising that all my database problems are linked to the attachment folder size)
We run ACT v9 ST Edition, 20 users (so full MS SQL Standard) and still have issues with attachment folder size - so it looks like the ST editions still can't handle large attachment sizes.
We are going to upgrade to v10 and could use the document shortcut links but these aren't suitable for automatically recording emails/letters/faxes etc are they?
Are there any plans to change these limits - I have been unaware of this problem and so it seems are UK tech support! - our company needs to record everything attached to clients and they're not going to be very happy if we have to keep removing history to keep the file size down??
The Solution offered by GL computing won't work in an environment where 1/2 of our users are operating remotely without access to network drives except when they come in to the office once or twice a week. Meaning that they wouldn't be able to have the linked documents located on a network drive with them in their car.
The other objection is that the process of striping the attachments out of the e-mail that they arrived with, saving them on a network drive and then pointing back to the e-mail attached to a contact without the attachments is just going to be such a cumbersome process that it's virtually unworkable.
RE to: Sarahwells post
1 St. Upgrade to v10 ASAP it's much more stable than v9, and don't attempt to use ACT! e-mail, it tends to crash loosing the preference file and all your e-mail folders once every 3 days to two weeks. Every crash takes about 45 min on the phone with tech support to get your e-mail back and the preference file has to be rebuilt from scratch. Outlook crashes every now and then but you don't loose anything and it starts right back up.
We are running v10 on the server with 9 users, 17,000 contacts and 13.9 GB of attachments (mostly e-mail) and it runs fine with two exceptions. You have to back up the database w/o attachments and then use a method outside of ACT! to back up the attachment folder. The second is somewhere a little above a remote database 4 gb attachment folder size, you can't cut or synch a remote database. This really gets to be a problem when you have a remote database that is working, and then the attachment folder grows to the size where it does not work. Now you have a remote you can't synch.
"The Solution offered by GL computing won't work in an environment where 1/2 of our users are operating remotely without access to network drives except when they come in to the office once or twice a week. Meaning that they wouldn't be able to have the linked documents located on a network drive with them in their car."
If the remote users have internet access, you could use something like FolderShare for the linked attachments
The nature of our business is very complex projects and a long sales cycle that requires us to keep history 5 - 6 years back. The "free" engineering we provide with a quotation and the confusion resulting from multiple inputs from different people over multiple years are what is driving the need to maintain a large history file. Bandwidth is not really a problem, week to week the amount of data that actually changes is not that much.
Separating the attached files from the e-mails that they arrived with will strip most of the desired functionality from the system.
Mike, I'm exploring the possibility of syncing the remotes without attached files. Providing the outside salesmen with Web access to the main database. Telling them not to attach files to their remote database. Then using an xcopy command to move any "inadvertant attacments" from their remote DB attachment folder to the main database attachment folder. This might give us a working scenario that while not perfect, may be workable.