Jump to content
Salesforce and other SMB Solutions are coming soon. ×

Archiving


Colin Weir

Recommended Posts

Im looking advice on how to implement archiving on FMP7. Say I have a client list- I use a value list to enter these details in active accounts into an invoice. Clearly over time this list will become large with redundant entries.

 

Ive searched but cant find a way to do this. I understand another table duplicating the fields would be needed, but how would I script this and attach to a button so that records are moved to this archive and vice versa so that they no longer appear in the pop up menu in the value list?

 

Thanks in advance as ever -usually my stupid questions have simple answers!!

 

Colin

Link to comment
Share on other sites

I'd recommend leaving those inactive record in the existing table, and using a status field to mark those that are "Inactive". You can make your value list conditional so it only shows those that are Active. For finds in that table, you can have the status field defaulted to find "Active" records only, but allow user override if you wish.

Link to comment
Share on other sites

So I am curious Ender.

 

Would this be practical in say a case where I am creating a record for each job we do at our shop. When the job ships and is billed we toggle a field to indicate it is now "archived" but leave the record in the active table. After we do 10,000 jobs wouldn't that slow our active table down a bit? Just wondering. I am asking because at this very moment I am creating a seperate "JOBS ARCHIVED" table which I plan to populate with completed job records deleting them from my ACTIVE JOB table. When we repeat a job I intend to allow a person to locate a job in the ARCHIVED table and we would then generate a new job record and copy over any pertinent information from the archived record. I am not convinced that what I am doing is unecessary. But if it is than I should re-consider my approach and maybe save me a lot of time. The CRITICAL factor is that I want the ACTIVE job table to be very FAST when it comes to access. Anybody pulling up active jobs at a terminal anywhere in the plant should get fast access. I don't want them standing around twiddling their thumbs while the database grinds through thousands of records before displaying the one they want on the screen.

Link to comment
Share on other sites

If your searches are on indexed fields, or you use relationships to show active Jobs, then you won't have time to twiddle your thumbs. Even with hundreds of thousands of records, searches on indexed fields are very fast. And with FM7 (especially with Server,) searches on unstored calcs are also pretty fast.

 

I would still recommend keeping the completed jobs in the same table, at least until you're pretty sure you won't need them anymore. You might remove old Job records (saved in an offline archive,) after a year of two of inactivity for that customer.

 

The search or relationship to show these active records will take just a second or two to show, and require just one or two field updates. Going with an "archive" file or table would take about the same amount of time to show the records, but would take longer to move the entire record and delete the existing record. You'd also have to be careful to trap for errors so that a record won't be deleted if its archived version didn't copy correctly.

 

As Ray points out here:

 

http://www.maclane.com/ubbthreads/showflat.php?Cat=0&Board=40&Number=499619

 

It's also harder to search for records it they could be in two places. I would add to this that it's harder to summarize records if they could be in two places.

Link to comment
Share on other sites

Ender, keeping in mind my portal problem, does all of this change at all when you're no longer doing finds/sorts in favour of dynamic, filtered portals?

 

I'm contemplating the creation of a file or table to archive or 'de-commission' finished orders, actions, etc. for two reasons:

 

1) A different table could be set up so that only the necessary data is kept and is stored in a read-only fashion to creat a non-modifiable history.

 

2) Well, the obvious - keep the main, or active file trim, easing the strain on all the relationships, etc that some of my layouts' portals rely so heavily upon.

 

What do you think?

Link to comment
Share on other sites

I don't think the use of relationships over Finds & Sorts changes things. I'd still go with one table per entity, keeping completed records in the same table as the active ones.

 

1. I should think this "read-only" capability could be managed easily enough with careful construction of the interface, and the correct Access Priviliges.

 

2. While there could be some "strain" on the system, having to send more index information over the network, it's been my experience that a bigger factor is the number of related records in the portals, and how complex the sorting of those portals are.

 

I'm still pondering your troubles in the other thread, frigante. I figure something will percolate sooner or later.

Link to comment
Share on other sites

ThanksEnder for all this. Some feedback from me.

I have implemented this advice and that from Cobalt Sky which reinforced that. Im am reassured now since at present my active list runs into hundreds not even thousands.

It's forced me to understand conditional value lists and have used this to filter for my active clients.

If I used a (filtered) relationship in a large list (thousands) would there be a performance gain over the value list method?.

How would I do that?

Link to comment
Share on other sites

Well, maybe that's my problem, Ender - I'm using up to 3 different sort fields per portal. A time-based sort, and two text-based sorts. I failed to mention that in the other thread!

 

Each portal's main relationship, therefore, has three sort criteria. Perhaps I should consider removing one or two to see if that improves performance. I doubt this is what is causing the spinning wheel syndrome I'm experiencing though. But I could be wrong - tell me I'm wrong!

Link to comment
Share on other sites

[ QUOTE ]

If I used a (filtered) relationship in a large list (thousands) would there be a performance gain over the value list method?.

 

[/ QUOTE ]

I'm not sure what your 'value list method' is. A conditional value does use a filtered relationship.

 

 

Frigante, I know portal sorting has improved in FM7, but I haven't tested it much, so I can't say if this could be the problem. I know in FM5/6 I had a beautiful interface screen set up with a portal that sorted by three different fields. It worked great on the 100Mb LAN, but was unusable on the WAN. (I ended up switching to a List View.)

 

Anyways, this should be easy enough to test by simplifing the portal's sort to one field, and seeing how it does.

Link to comment
Share on other sites

Sorted!

My method was way too complicated -it was actually based on the method in the help file in FMP7. Simply basing the relationship on an active="YES" field on both sides works. Which is what you suggested at the start.

Link to comment
Share on other sites

Ender, just out of curiosity, what do you mean by "WAN?"

Wide Area Network (as in the internet) or Wireless Area Network?

Link to comment
Share on other sites

WAN = Wide Area Network. I haven't heard of "WAN" referring to a wireless network. Maybe that's a Canadian thing. You Canadiens always have to do things a little different. wink.gif

Link to comment
Share on other sites

I've never heard it used that way either, but you never know.

Canadians have to do things different!

 

So are you talking about web access when you say "on the WAN" or are you talking about a bigger network like the entire company vs. one floor or office?

Link to comment
Share on other sites

Ya, dat der WAN for us is remote locations, ya know. In general, these connections can be through DSL, Cable Broadband, or T1, with or without VPN.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.



×
×
  • Create New...

Important Information

Terms of Use