Duplicating Tables

[MacHammer]

Hi everyone,

I know that I've seen this here in the forums, but for the life of me I can't find it again...

I have two databases and I want to add the functionalities that I've developed in one to the other. So I want to duplicate the layout and the field definitions that go with it. As there are a lot of calculations involved in the table that I wish to export, I don't want to have to re-type the defs and risk making a typo mistake, thereby blowing the functionality of the calcululations.

So, how do I "export" the field definitions from one database and "import" them into another?

Thank you!

Mac Hammer

[jteich]

With FM Advanced 8 you can copy fields and tables. Only layouts can not be copied as a whole.

-jens

[Søren Dyhr]

This tool

http://www.quart-edv.de/plugins/pasteboard_en.html

With fm8+ in adv. version! Prior to those dope the file, and rewrite the cloning.

--sd

[mr_vodka]

Why cant you just copy the table and past it into the new database? There will still need to be some clean up but at least you wont have to retype everything.

[MacHammer]

Because, as far as I can tell, there is NO way of copying a table. Hence the question. I can copy a layout and paste its objects into another database, but the all-important field definitions that drive the whole process stay in the original database.

Mac

[MacHammer]

And I guess I need a solution that is going to work in FM 8.5 and not Advanced.

Mac

[mr_vodka]

Oops. Sorry missed that one. You may be able to still use FM Robot but you will have to buy it.

http://www.newmillennium.com

[Ender]

Hi Mac, you could also import the table definition by choosing New Table in the upper right menu in the Import dialog.

But I hope you're not doing this to have duplicate tables within the same solution. That would be a design mistake that is a pain to deal with.

Perhaps you're doing this because you have done work in an offline development database, and now you wish to move that structure into the current system?

[MacHammer]

Thanks Carpal,

Like I mentioned above, I have a functioning module I developed in one database, and now we want to add that same functionality to another one of our databases. I'd like to be able to copy the layout objects and paste them into the new database, then copy the field definitions that drive them (and all of their lengthy calculations) out of the working dB and then move them into the second dB.

Thanks.

Mac

[Ender]

It's still not clear if this module is being duplicated for the same solution or if it's just being moved into a new location. My caution about that still stands.

The usual method for moving everything from one file to another (short of using FMRobot) is:

1. Import or retype the fields.

2. Add any necessary relationships, making sure the TOs have the same names.

3. Define blank layouts with the same names as those from the original file.

4. Copy and Paste any necessary value lists.

5. Import any necessary scripts.

6. Copy and paste the layouts.

7. Go back and fix any calc definitions that were commented out.

8. Test everything.

[MacHammer]

It's still not clear if this module is being duplicated for the same solution or if it's just being moved into a new location. My caution about that still stands.

I have two databases and I want to add the functionalities that I've developed in one to the other.

I have a functioning module I developed in one database, and now we want to add that same functionality to another one of our databases.

Different database. New database. A second database. An entirely other database utterly apart and different from the current database. A database that is almost exactly like, except for the fact that it is completely different in all other ways, than the first database. :

Sorry to get cheeky, but I try to write complete descriptions so that you all have the info you need to help me. I thought I'd err'd on the side of being over-verbose in the original question.

I DO appreciate the help. I guess I'm just trying to avoid the usual method of doing it. I guess I've reached the point where I need to ask the boss for a copy of FMP 8.5 Advanced.

Thank you again! Please look at this post with tongue in cheek. I don't want to offend at all.

Mac

[Ender]

Without a description of the "module", it's hard for us know if what you're doing is appropriate or if there's a better design. The term "database" could be interpreted to mean a table, a file, a module, or an entire solution, so I gave it to you both ways: 'This is how it's done, but it may be a mistake if you're putting duplicate tables within the same solution.'

I hope you do get FM8.5 Advanced, as it has many other great features, things that are especially helpful for complex solutions. But just so you don't get the wrong idea: having the Advanced version will simplify step 1, but everything else is the same.

Anyway, good luck!

[Søren Dyhr]

'This is how it's done, but it may be a mistake if you're putting duplicate tables within the same solution.'

I had the same prejudice suspition right from the start of this thread! And if we're into modulization might services be made as independend files where other solutions subscripe to these by advanced parameter transferes like:

http://edoshin.skeletonkey.com/2006/02/options.html#more

http://clevelandconsulting.com/support/viewtopic.php?t=1345

...as seen in this movie:

http://www.filemakermagazine.com/modules.php?op=modload&name=News&file=article&sid=622

(subscripers only!)

--sd

[MacHammer]

Geez guys.

I've got a robust address book module that is needed in a second entire solution for a different part of our company. I want to move it in and relate it to that solution. That is all. Period. Someone from another side of the firm saw the address book module in someone else's database and asked me if she could get something like that in hers as well. It took a long time to get right and I would simply like to copy it and move it in without re-doing the whole stinkin' thing. How difficult do we have to make this? Please quit trying to assume facts not in evidence. I have told you all now, I think, three times (and now four), exactly what I was trying to do. I can not, and will not, attempt to make it any clearer. I have a job to do, and apparently it involves retyping about 200 lines of code because Filemaker can't see fit to realize that we might want to re-use a good tool in a different way, and since both of my ENTIRELY SEPARATE (5) databases are existing solutions, I can't just gut one and start over. I simply want to add a contact/address table, with all of its nice calculations, into the second ENTIRELY SEPARATE (6) database.

I truly appreciate the help, I do. But please...

Thanks, and good night. Don't forget to tip your waitresses.

Mac

[Søren Dyhr]

I simply want to add a contact/address table, with all of its nice calculations, into the second ENTIRELY SEPARATE (6) database.

Split what you have into two files then, one service part and one subscriper part. - dupe the service part of the divide and use the file as is in the new solution. Since you're on fm8.5 should the service part be entirely without layouts ...leaning towards the separation model.

http://www.newcenturydata.com/downloads/separation_demo.zip

Geez guys.

Please note that I do not take a pride in being too prejudice, it just escaped me. But you have to realize that "enough to go on" isn't always enough for us mere mortals.

Rumors and guesswork is usually an attempt to fill the gap between what is fact and what it seems to be!!! Economizing with informations kept in a too generalized manner, doesn't hardly ever get debate forums to be spot on in first attempt.

Why couldn't we have the story about the trespasser eyeballing your solution right away??

--sd

[MacHammer]

Sorry.

Mainly because the only question important to the discussion was simply: "How do I duplicate a table into a different database".

The rest of the story was simply to give a small basis for the main question. It didn't change the "question". Knowing the "more" doesn't add to the "how to". By adding the "more", I was simply trying to impart the human element. I respect you all more than a reference guide or a search engine. I'd already tried both of those to no avail. So, I asked a question, hopefully written with enough respect and detail to get the expert assistance I needed. And, mostly, it has worked...

Thank you all, again and again. I'm about a third of the way done with the "copying" of the table into the second database. I don't mind telling you all that this really sucks, though. It should be easier. Adding a "Copy Table" button to the Define Database screen would save us all a ton of work.

Mac

[Ender]

Why didn't the Import work?

[MacHammer]

The usual method for moving everything from one file to another (short of using FMRobot) is:

1. Import or retype the fields.

2. Add any necessary relationships, making sure the TOs have the same names.

3. Define blank layouts with the same names as those from the original file.

4. Copy and Paste any necessary value lists.

5. Import any necessary scripts.

6. Copy and paste the layouts.

7. Go back and fix any calc definitions that were commented out.

8. Test everything.

Since there is no way to import, I'm retyping the fields, per step one. And importing to f1, f2, f3, etc. is completely unhelpful, so I'm copying field by field, definition by definition. Its lots of fun.

Mac

[Ender]

Try this quote instead:

Hi Mac, you could also import the table definition by choosing New Table in the upper right menu in the Import dialog.

[MacHammer]

OK, so you guys aren't the only ones that can't read...

I guess that will give me the field names, at least. Well, only 10 more to go anyway...

Thanks again.

Mac

[Søren Dyhr]

The rest of the story was simply to give a small basis for the main question. It didn't change the "question". Knowing the "more" doesn't add to the "how to".

Are you sure about that?? I've just read this:

"asked players of various strengths to reconstruct chess positions that had been artificially devised--that is, with the pieces placed randomly on the board--rather than reached as the result of master play. The correlation between game-playing strength and the accuracy of the players' recall was much weak-er with the random positions than with the authentic ones. "

...snipped from: http://www.sciam.com/print_version.cfm?articleID=00010347-101C-14C1-8F9E83414B7F4945

According to it should a correct diagnostic procedure follow a thread instead of jumping straight to the throad, following a thread means instantly recognizing patterns and images ...and not be a question of analysis every time to pick the right piece to move.

I think you are not right when ignoring apperception, which is: To perceive new experience in relation to past experience...

--sd

[Ender]

Thank you, Confucius.

Mac, I'm glad you got it figured out. I kept wondering what you were going on about when the solutions had been given.

Soren and I are just trying to help you avoid a common pitfall in design. Believe me, I read your descriptions thoroughly, but like I said, there are different ways to interpret the terms (like "database"), and it wasn't clear from your description. It occurs to me now that maybe your different "databases" are stand alone (not hosted), and that's why the module must be reproduced.

I don't know. This may be one of those "Who's on First?" situations, where we just won't grok what the other is talking about. I know I feel that way when I'm reading Soren's esoteric babble. :shocked:

[MacHammer]

:P

Mac