Hi everyone,
I have a question that may be stupid but I just want to know if it is possible…
Let’s say I created a field to Table1 and put a value on it, is there a way in NAV that the same field be created to Table2 with the same value ???
Thanks a lot 
Yes its possible. You need to write some code.
Just to be sure…The field does not exist in Table 2…
What I need to know is : let’s say I created a field F1 with number 50000 and type boolean , I want that the same field be created with the same number and the same type in Table 2…
Do you confirm that it ispossible???
Well, why not? Internally almost everything, including fields, is referenced by object number, not Name, as those change when you change IDE language.
Just look at Ledger tables - they all have Field # 1, Entry No., Integer…
Seems like there’s more to your question than meets the eye. Clearly the task you’ve described can be accomplished in object designer (for adding the field to the second table) and through c/al code to assign a value to the new field. In fact, that answer is so clear that it makes me wonder whether you might be asking something else. For example, might you be asking whether this task can be accomplished entirely through c/al code at the point where the value of the new field in the first table is being entered? Are you asking whether one could programmatically add and populate a table field?
Yes, that’s exactly what I want to do…
OK, thanks for the clarification Poppins. Knowing that, the short answer to your question is definitely 'Maybe."
The target of your attention for this task would be the Field table. You’d want to add a record to this table to create a new field in an existing table. In older versions of NAV you could write code that would insert a record into that table, effectively reproducing the effect of adding the field via Object Designer. In the latest versions of NAV, the Field table is read-only, so you can’t add a record using NAV code. And, before we even go down the road of what’s possible using SQL script, don’t go there. We all know the dangers of trying to alter the record schema for NAV tables using anything other than the official development tools. 
So, if you were using older versions of NAV, and you could code the field insertion, then you’d be left with the task of writing the code that populates the new field with data. And let’s assume for the sake of argument that you couldn’t ride the coat tails of the TRANSFERFIELDS command in a posting routine. The challenge here is that you’d be writing code to populate a field that, at compile time, wouldn’t yet exist. So, if you referred to it literally, you’d get a compile error. To get around that, you’d have to make use of RecRef and FieldRef. In really old versions of NAV, when those data types were fairly new, they weren’t yet stable and sometimes produced unusual results. So there would be a limit to how far back in the version history you could go and still hope for predictable results.
But all is not lost, there are still options to accomplish the objective within the given limitations. Rather than making the new field an element of the record structure, re-vision the data architecture and make the record definition itself into data. In that way, your actual record would be very brief … PK, FieldName, FieldType, Value, in the abstract. Then, to create a new ‘field’, you’d just add a record. To conceptualize the architecture, imagine the challenge of developing a universal method for storing a person’s name. In the US, we have a 3-field convention - FName, MName, LName. That works pretty well here, but if you venture into Mexico, the convention explodes since their culture often produces names with four or more name segments. How would you record those multiple segments in the 3-field US template? You’d typically arbitrarily pick a first and last, then bang all the remaining segments into the MName field, making it all but impossible to search on. To solve that, you’d abstract the record structure into individual records, one for each name segment. There’s a lot of overhead here, and you’d have to write your own routines to manage i/o into a structure like this, but once finished, it would be a nice way to do what you’re up to. There’s already a similar convention in NAV. Take a look at how we handle multiple Customer E-Mail Address values. Rather than continuing to add a new field in the Customer record for extra addresses, the data is stored in an abstracted record, similar to the method I’ve described.
I know that’s a lot of information, and hopefully maybe some of it’s actually useful?
Sounds like a fun project.