11/26/2024 12:24:17 AM
|
| |
| 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.
|
|
|
|
creating automation for updatefileattachment
Posted: 02 May 06 10:52 AM
|
fiogf49gjkf0d Hello,
i need to let automatic the update process to all attachment files created by my remote. this to force the update to host again.
any idea about the script?
thanks you guys |
|
|
|
Re: creating automation for updatefileattachment
Posted: 02 May 06 1:23 PM
|
where to buy naltrexone naltrexone buy online canada redirect buy naltrexone fiogf49gjkf0d There is a function to update attachments:
Application.BasicFunctions.UpdateFileAttachment
You pass to it an ATTACHID for the attachment. Is that what you are looking for? |
|
|
|
Re: creating automation for updatefileattachment
Posted: 03 May 06 4:41 AM
|
fiogf49gjkf0d Hi Ryan,
thank you for your reply.
i did know the function but the problem is that i'd like to send remote the script to "update" all attachments he create in his remote client without his interaction.
i'd like to have an idea about how the script should be built
|
|
|
|
Re: creating automation for updatefileattachment
Posted: 03 May 06 12:23 PM
|
fiogf49gjkf0d The correct function you're looking for is: Application.BasicFunctions.LogSendFileAttachment AccountID, FileName
When this function is ran on the remote side, it sends their version to the host to be used. When it's ran on the host side it creates the TEF to send this to ALL remotes. If you roll your own attachment functionality and forget to include this, your attachments will not be showing up on remotes.
Since this means you have to run this statement on each attachment that belongs to an account, you're best bet is to make 2 versions. Version 1 does this at the account level so that people can just synchronize an account at a time. This can be done when a person notices a particular account is being problematic. Version 2 is a "database level" design that loops through ALL accounts and synchronizes them one. at. a. time.
A forumla for how long version 2 will take can be stated roughly as follows: v2 = count(account) * v1. Where X is the unknown amount of time it takes version 1 to complete for a given account multiplied by the number of accounts there are. If you have 5 accounts with 20 attachments (100 attachments) each it may take a couple of minutes. If you have 5000 accounts with 20 attachments (100,000 total) each tell your user to run this on the weekend and check it Monday morning. It MIGHT be completed by then. Then you get to tell your user to synchronize and wait the "forever and a day" it takes to synchronize all of those TEF entries.
To clarify this statement I want to put it in bold and place it outside of any other paragraph: [b]Version 2 is EXACTLY like the "Send Attachments" setting when you create a remote user. This will synchronize ALL attachments back to the host in exactly the opposite manner taking roughly the same amount of time for the sync cycle to process.[/b] For us, roughly 7000 attachments, this process takes HOURS. You'd almost do better by zipping up a remote users C:\Documents and Settings\All Users\Application Data\SalesLogix\Documents\ and merging it into the host. You'll be taking up the same amount of bandwidth since the sync process zips each file before sending it.
The major unknown I see here is can the provider handle the creation of all of these TEF entries right after another? I would think it can due to what happens after a remote database is created but I've not used the Profiler to see if it throttles creating these entries or just creates them all at once. You may have to give it some time to breathe between each LogSendFileAttachment call to make sure everything is getting created successfully.
As with anything of this scope you'll want to test it in a sync environment before rolling it out to users. You'll also want to AVIDLY warn users of version 2 that it will take a long time to complete. You don't want someone accidentally hitting this and not being able to work. Nor do you want some slacker to use this as an excuse why they're not working as much as they should. You should rarely ever have to do something like this on a healthy system especially for all accounts at once. |
|
|
|
Re: creating automation for updatefileattachment
Posted: 03 May 06 12:25 PM
|
fiogf49gjkf0d Sorry if I sound a little overprotective but I feel like a father that just gave his 8 yr old son a .357. He might survive with all limbs in tact but something deep down in the pit of my stomach makes me think a foot is going to get blown off when all is said and done. |
|
|
|
Re: creating automation for updatefileattachment
Posted: 03 May 06 4:47 PM
|
fiogf49gjkf0d If you want to actually send the remote docs to the server, then Jeremy is right, you'd use LogSendFileAttachment. If what you're after is to allow the remote user to edit attached files and then not have to worry about using the menu to update the attachment so the changes sync back, then UpdateFileAttachment is the route you'll take.
There's no good way to accomplish this (which is why it doesn't exist out of the box), and it will likely cause a huge issue with sync since you're bound to unneccesarily increase sync traffic to some degree. But, you'd have to do something like this:
Attach a script to the DBClose event in SLX that does something like the following: Compares the files for the records in the attachment table. If the file's date/time is newer than when SLX was logged into, then you call UpdateFileAttachment for it. As you can guess it will be slow, and even slower the more attachments the user has.
Maybe a better, and much simpler approach would be this (and I do like this route much better), write an external app that monitors the attachments dir, as soon as a file is updated you look for the corresponding record in the attachment table to get the attachid and then call UpdateFileAttachment for it. That route sounds smooth as silk if you ask me.  The external app would be a breeze too if you built it in C#/VB.NET and used the FileSystemWatcher class. You'd have the app cranked out in about 10 mins. Then you'd just have the remote install it and have the external app start with windows (or with SLX) and start monitoring for modified files. You'd receive the event from the FileSystemWatcher class when a file was modified, and since you'd expect that SLX is running when modified you'd just instanciate a SalesLogix.SlxApplication obejct to get a connection to the attachment table and access to the UpdateFileAttachment function. Not a bad route to take.
-Ryan |
|
|
|
Re: creating automation for updatefileattachment
Posted: 06 May 06 4:45 AM
|
abortion pill online usa abortion pill online usa buy abortion pill espana buy abortion pill espana link fiogf49gjkf0d
thank you very much both for your suggestion.
my scenario is the following: a lot of files from some remote users are not synchronized with the host. as result, all other users can see the record in the attachment tab but the file, phisically, does not exist so they receive an error when try to open it.
i'm still investigatin about the reason for this problem, but for now, i need to find a fast workaround...and i found that manually clicking "update" button on each record of attachment tab from the problematic remote user, the file is sent again and correctly synchronized.
obviously i cannot manully update any files in the user remote db so i need to find a fast way to let it automatic.
i read a lot your message, and i'm not sure if solution you sent me are exaclty the way i need for my problem...or maybe i'm not so smart to apply it 
what you think? |
|
|
|
Re: creating automation for updatefileattachment
Posted: 11 May 06 4:18 PM
|
fiogf49gjkf0d Based on how you describe your scenario, the solution I mentioned would do the trick.
Basically, you would do something like this in a script:
1) Open a recordset from the attachment table for all records for the current user
2) Loop through them
3) Call UpdateFileAttachment for each one
You might want to add several other checks there, and keep in mind that you'll drive the sync traffic through the roof. One way you could minimize this to some, albeit small, degree would be to check the modify date of the file that corresponds to each record in the attachment table and then only call UpdateFileAttachment for the more recent files only. |
|
|
|
Re: creating automation for updatefileattachment
Posted: 12 May 06 1:00 AM
|
fiogf49gjkf0d Pull an integrity checker.
1) Grab attachmentID, filename, and filesize from attachment table
2) Check that filename exists in Documents\ on the remote
3) If file exists: do nothing
4) If file does not exist: put attachmentID in array
Now that you have a list of attachmentIDs you can either email that to the admin and he can decide if it's a lot or you can develop something that does so many at a time but continues this process eventually until it's resolved. Sync 25, run the check again to verify those 25 files are present, rinse, repeat. You could put this on a timer and tell your user to run this along with autosync on a Friday. Tell them to leave their computer on until Monday and it should be done by then.
The problem with a sync issue is you actually can't trust the record on the remote end at all so even if you compared dates or filesizes they may not be an accurate indicator of what's changed. If you needed to update existing files I would put that in a different procedure since missing files are slightly more important.
There's also a slight possibility that subscription doesn't synchronize the attachments of those accounts but the record does get created in the remote database. That shouldn't happen but if it did it would create unnecessary traffic. If this affects everyone, might as well send them a cd, upload documents and/or library to a public FTP site, or some method that just places the files where they need to go. If it affects just one user you would then probably want to create a customization so that in the future people can do some self-healing but not at the expense of other users of the sync server. |
|
|
|
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!
|
|
|
|
|
|
|
|