11/22/2024 3:56:40 PM
|
| |
| slxdeveloper.com Community Forums |
|
| |
|
|
The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
Forum to discuss writing script in Architect plugins for SalesLogix & general SalesLogix customization topics (for Windows client only). View the code of conduct for posting guidelines.
|
|
|
|
Attachment Tab Overuse?
Posted: 04 Apr 06 8:17 AM
|
fiogf49gjkf0d My company LOVES the attachment tab. They love it so much it's become the default document management system for a year and a half. Now there are so many files in the attachment directory Windows is having a hard time finding them all. We need to break this up so directory services doesn't come crashing down one day.
I would love to break that up into smaller chunks - say by quarter - each into a separate directory. However, SLX doesn't store the attachment path inside the attachment table, so if I change the path at any point, I've broken all the current links inside the sales client.
Any suggestions on what to do outside of writing my own attachment tab? (Grrr, must I write everything?)  |
|
|
|
Re: Attachment Tab Overuse?
Posted: 05 Apr 06 1:01 PM
|
fiogf49gjkf0d You have to write your own to achieve that functionality but the fun part is sending the file itself. LogSendFileAttachment works for normal attachments and sends the file TEF down but I don't know of any way to send down directories or contents. The best thing that comes close is the Library and all of it's stuff is internal to Administrator.
A long time ago during 4.0 days we had some attachments with names like Fax\Filename.doc that apparently went to a folder. I believe they were just attached incorrectly due to a bug in the design but it may be possible to trick it using naming conventions like that. The major problem with this is the directory has to be created on the remote BEFORE a file can go into it and the normal sync process will NOT do this for you.
Personally, I'm thinking about some kind of service that exists on the host and remote machines that will send attachments down and handle the mapping. You're severely limited using the existing LogSendFileAttachment routine and I don't know of any other way of sending the file unless you're putting blobs in the database and I normally don't do that. The database is bloated enough as it is with just text data. Adding some more binary to the mix would just make things a lot more complicated. |
|
|
|
Re: Attachment Tab Overuse?
Posted: 06 Apr 06 8:24 AM
|
fiogf49gjkf0d We won't be synchronizing any data with remotes, so that's not an issue. Frankly I lost too much hair back in the BP days with sync.
... Looks like another project added to my design queue. |
|
|
|
Re: Attachment Tab Overuse?
Posted: 07 Apr 06 9:40 AM
|
fiogf49gjkf0d For a good example (if you want to keep it in the database) use the LibraryDocs/LibraryDirs tables that build the SLX Library. It's a great way of storing the "filesystem" if you want to call it that.
You could make a MainView that handles both attachments and the Library in the same manner. Or you could simply blend both, allowing the ability to "attach" a library document to the attachment table. Since sync isn't an issue, you have the ability to pretty much do anything.
Some ideas popped in my head:
1) Subversion repository to store everything with a history of each attachment. This way instead of having FileName (Year) with hundreds of attachment records you just drill down to the version created that year.
Example: Our company has a number of anywhere from 3-5 files that are pretty much attached to every account we do business with and these files renew every year. Want to go back to 1993? Get ready to scroll down sucka!
2) Volume Shadow Copy(VSS) could perform the same basic functionality. The concept is delta binary changes rather than full copies of the file.
3) CRC32 comparison of files to a hash table. If the CRC32 value is found, you have an exact duplicate file. No duplicate files, just duplicate links. Subversion or VSS may take care of duplicates in this manner though I'm not quite positive.
4) Cache directory structure sublevels if possible to eliminate requerying the database with every click. Explorer I believe caches at most 4 sublevels.
5) Any combination of the above basically spells out a fancy "Document Management System". Charge thousands of dollars for the concept alone. When you mention document management you automatically are accepted into the "big bucks" category.
6) Retire within a week.
Pros and Cons
Con:
1) CRC32 can take a while to calculate and grows exponentially with filesize
2) Connecting to subversion or vss to view history takes a while to execute
3) Trying to built a subversion or vss client on your own in vbscript is impossible. (I'd use TortoiseSVN and the vss commandline stuff from MS.)
4) Users cannot access files by \\Server\SyncLogs\Documents\ any more but this leads to a pro.
5) Using TortoiseSVN has most of the client outside of SalesLogix. You basically are now relying on 2 programs instead of one which isn't necessarily evil.
6) Subversion repository corrupts and you're toast.
7) There's no guarantee it'll be responsive enough for users to actually use it.
8) Training would probably be required for all of this.
Pro:
1) Working copies of attachments are used in editing. "Update attachment" would checkin a new version when the user is done. This gives them free reign to obliterate the file without you scrambling to a backup to recover it.
2) Text based documentation could use TortoiseMerge to merge/diff changes. The Con is it probably can't do anything with a Word doc.
3) You can see which user made changes instead of trying to rely on modifyuser/date.
4) Subversion can be backed up and recovered so even if corruption happens you can generally go back to a working state
5) You can bill for research time since you generally won't be proficient overnight though the learning curve is rather quick (perhaps it's just me though)
There's probably more I haven't considered but if I didn't have sync to get into I would eventually incorporate some or all of these ideas. I can't tell you how many times I've had to revert someone's changes or fix attachment issues that shouldn't have happened in the first place. Provided it isn't slow as dirt it could probably be pulled off too. |
|
|
|
You can
subscribe to receive a daily forum digest in your
user profile. View the site code
of conduct for posting guidelines.
 Forum RSS Feed - Subscribe to the forum RSS feed to keep on top of the latest forum activity!
|
|
|
|
|
|
|
|