Jump to content
Sign in to follow this  
DataChris

Duplicate Table

Recommended Posts

DataChris

Does anyone know how to duplicate an entire Table in FM7 (adding it to the same file)?

 

Possibly an export/import trick?

Share this post


Link to post
Share on other sites
Ender

There is no built-in functionality for this in FM7.

 

You might check out FM Robot from New Millennium. It's a tool that can import or duplicate tables.

 

I think the original thought FileMaker had in not including something like this is that it should not be necessary to duplicate tables, since each table should be about a different type of thing.

Share this post


Link to post
Share on other sites
Guest Yukon Cornelous

[ QUOTE ]

 

 

I think the original thought FileMaker had in not including something like this is that it should not be necessary to duplicate tables, since each table should be about a different type of thing.

 

[/ QUOTE ]

 

 

I think that there is an need for duplicated tables.

If you have Open Orders, When they are done archive the records to a Closed Orders Table by either Importing or scripting a new record/Lookup to Closed from Open and then delete the record from Open.

 

I have not tried it yet but I heard you can add a new Occurence Referrence to the table?

Share this post


Link to post
Share on other sites
Ender

Aside from the possible case where a developer likes to start every new table with the same set of developer fields, I would argue that there are very few times when it would be necessary to duplicate a table. The case you describe is not one of those.

 

For things that change status, like Orders, it is easier and safer to simply change a Status field on the record, than to deal with moving the record to another table and deleting the original. The records can then be filtered in finds, relationships, and security access by that status.

 

The "Occurence Referrence" you may be thinking of is probably the ability to access the same table via different relationships. In FM7, a table can have more than one Table Occurence, which can be linked via different relationships to the rest of the solution. Note that adding a Table Occurence is a simple matter of hitting the little add button. Adding a TO creates another view of the table, but this is not the same as duplicating the table itself.

Share this post


Link to post
Share on other sites
Robert Schaub

I don't know, I tend to agree with Yukon. I have been in the manufacturing business for over 11 years now. To have less confusion it has always been in our best interest (since FP3) to export the completed records to a file(table) for safe keeping. When you have 30 plus users (which range from harmless to possible disaster creators) accessing open records there is absolutly no need for them to stumble onto completed records and change data if not delete important information.

 

We have always a marked records complete and each morning run a startup script to move the completed records to a complete file. Here the records are still accessable , but with less access rights.

 

How was the the Complete file created in FileMaker 6 or less, It was Duplicated copy of open orders (which is not availabel inside the same file in FileMaker 7, However I think this will change in 8) and then make a relationship by Order Number and redefine all fields to lookup info in the open Orders file. After the export of closed records in the open file is done, another script is run to delete these records for Open Orders.

 

From there we are able to send out invoices based on daily complete files, But that's another story.

 

 

 

 

BTW: FMRobot is a good tool, But it requires xml reports generated from ddr in FielMaker Developer.

 

Share this post


Link to post
Share on other sites
Pes

I tend to agree with Chopper and Yukon.

 

When you have a QA system where a given procedurerequest is not having completed records in an ‘active’ file/application, you have to remove those records.

On the other hand, to be in accordance with (again) another procedure (the traceability), you need ( a restricted) access to those records.

 

Simple task is then to move those records to a ‘consulting’ file/application.

 

You could build a nifty system where a search result will display which records are in the ‘active’ file/application and which are in the ‘consulting’ file/application.

 

We have such a system for years now, and none of our users are ‘highly confused’ (like some seems to be) with this way of working.

Share this post


Link to post
Share on other sites
Ender

It's great to have you guys chiming in.

 

One of my arguments against this idea of moving records into an archive file/table, is the complexity of the scripting required to syncronize the move, and the chance that records could be lost if something goes wrong. You can see some past discussion about this in this thread:

 

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

 

There's also a good chance you'd be giving yourself double the work to do on any changes or additions for these tables (if you work by contract, maybe this is a good thing?!) Every time you add a field, change a relationship, or modify or add a report, your users will expect the new functionality will be available in the archived records. This means doing the change for both tables.

 

Another problem with the archive file/table approach is the difficulty and confusion involved in searching for a record. Which table does the user search in? Or do we need to script a search in both files/tables? In that case, how do we show the found set for the two tables?

 

I'm afraid I'm still convinced it's easier to keep the records in the same table and change a Status field. There's a little work involved in setting up the structure and interface to keep these records hidden for normal browsing or searches, but once it's set up, there's no additional work. And there's no issue with a record disappearing from a corrupt move to the archive. Security can be managed on a record-by-record basing, locking those with a certain status for some or all users.

 

Pes, not being familiar with the "QA system" you mentioned, I'm at a disadvantage. Is this a 'Quality Assurance' procedure you are required to follow? It would be good to know how such a system allows for correction of mistakes in archived records, and why this is better than keeping them in the same table.

Share this post


Link to post
Share on other sites
Robert Schaub

Looks like will will not change each other mind.

 

See FMProIt

 

Looks like Import tables will be available in 8, Why?

 

What are DataCris's intensions?

 

Going away for a week , no phone , no computer , just fishing and Beer.

Share this post


Link to post
Share on other sites
Ender

Hey Chopper,

 

I see you're still fond of this idea of a separate table for archived records, I'd just like to understand the attraction.

 

To me, this seems a little like the use of repeating fields for line items. They're pretty easy to set up initially, but end up giving you problems down the road.

 

[ QUOTE ]

A few changes here and there , no big deal. A major change ..Oop Duplicaticate the table again import from old table...change the relationship to new table..maybe alter a few scripts and back in business.

 

[/ QUOTE ]

You make this sound trivial, but with complex solutions, either of these options can be maddening. Having done some double work getting our FM7 solution to match our FM6 solution prior to switching, I know how difficult this can be.

 

Take for example the minor changes. In the process of adding a report you might need a new field, a new layout, and an addtional script. It doesn't make sense to put every change in both tables until you know you have the report debugged in one, so you get it all working for one first. Now it's time to do that same report for the second table. "What was that new field again?" "Let's try the script...didn't I already do this?" It is easy to forget which parts were already done and tested in the second table since your memory tells you it's already been done.

 

To me this is maddening. To you, well perhaps you're already mad and don't notice. wink.gif

Share this post


Link to post
Share on other sites
This thread is quite old. Please start a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  



×
×
  • Create New...

Important Information

Terms of Use