No-permission-to-create-a-field-workaround: Table generator

Administrator · 2007-03-20

No-permission-to-create-a-field-workaround: Table generator
You all know the problem:
You did some customisations on a table. You want to apply a new hotfix, which adds a new field in that table. You start merging, and want to import your txt. You have no permission to add that new field from that hotfix into a table.

Here is a workaround in case this happens a lot for one hotfix/localisation/add-on/whatever:
- You create a new default NAV db (without data) with the new objects imported (import the fob in it).
- import this tablegenerator
- start form 70020
- fill in the tablefilter for all NAV tables that were changed (by the hotfix/add-on/...)
- select an empty map and press OK ... the tool creates some txt-files
- start form 70022 to create one large file
- import this file into the same database
- compile
- export the fob
- import it into the database you should import it with "merge exsisting <- New" ... your fields have been created
- overwrite the objects with your merged txt file (which gave the error in the first place

This is a tool that has been written in spare time ... so as quick as possible ... so don't be too critical about it

http://www.mibuso.com/dlinfo.asp?FileID=817

Discuss this download here.

Waldo · 2007-11-16

In thisthread, I tried to explain the workaround in other words.

I created a workaround to merge two add-ons. It comes down to:
- create tables without code and fields with those numbers
- create fob
- import fob: Merge Existing <- New
- import merged textfile.

Once, I put a download on Mibuso:
http://www.mibuso.com/dlinfo.asp?FileID=817
This tablegenerator creates the tables for you without code.
Import the generated text file in (a copy of) the existing database where you uploaded the Add-On in, compile the tables, export as fob and import it in the database where you would upload your merged textfile in (import Merge Existing <- New). Now, your fields that you couldn't create, are created.
Remember to work with databases without data (so without companies).

When you have your merged text files, it just takes an extra 10 minutes with this workaround for all your tables.. (no matter how many).

rdebath · 2008-05-08

:-k I think there's a simpler solution to this ... use the field table.

In your modified database; export the entire field table.

In the new Cronus (or no-data) import every field you can, insert them into the field table. This won't create tables; you'd have to use the object table for that.
Also extend every text field that's longer in your database and any similar upgrades that the FOB import can do by itself (eg: int->bigint).

All the modified objects in the new Cronus should now import nicely into your working DB (if Microsoft hasn't broken the Cronus overlay that is) and make it ready for TXT imports.

Do NOT try the dataport import on a database with a lot of data; it will work but VERY slowly becuse each Field.INSERT is a table redesign.

Waldo · 2008-05-08

Ah, that's a good approach.
But isn't it a manual job, or how do you automate it?

hm, may be reading the field table of the new db, filter it, get the fields in excel, and import excel in the field table of the new db... .

hm... :-k . Nice one.
Should think this over :-k

Thx!

rdebath · 2008-05-09

I don't see why it needs to be more that an export + import.

The export can export everything.

The import checks the data that exists currently in the new DB and uses a few simple rules to throw away rows it can't use.

eg:
If either the field No or the Table No is in 50000..99999 and the field doesn't already exist it can be created IFF the table exists.

Otherwise the field can be modified if the new column type is 'better' in some way.

Sounds easy.

No-permission-to-create-a-field-workaround: Table generator

Comments

Categories