Hi everybody,
It’s been a while since I posted here, but I’m always around, learning new things from you, so thanks for keeping the community alive.
I’ve a question for you.
I need to export our (very big) dictionary to .dctx, bulk modify it (renaming, adding fields paying attention to uniqueness of GUIDs, changing data types, …) and then reimport in a freshly created dictionary. It is a one time project, not something I need to do repeatedly.
I’m trying to understand if dct import/export is reliable and if I can trust this steps.
Our dictionary is very old and it has various issues I’m trying to fix to try and make this project as flawless as possible, the first version was created with Clarion DOS 3.1 and now we are developing with Clarion 10.
I noticed in the exported xml (dctx) that some table relations are changed and this somewhat worried me.
So I’m here to ask you if, as far as you know, .dctx import/export has some major bug that would prevent me from using it with peace of mind.
Thank you for your replies but probably I’ve generated a little misunderstanding.
I’ve no problem with GUID. If I’ll need to add new fields I’ll take care of generating a new unique GUID.
So, no problem there.
BTW, searching in the ClarionHub messages I found a few old messages suggesting that exporting and then importing a dctx is not totally reliable.
I have done this before using Visual Studio and a c# console app.
VS has a handy paste feature if you have a source document open. You can copy your xml to clipboard and then paste as special which will allow you to generate a C# representation of your xml file. This can then be used with some simple code to load, manipulate with linq and then save back to xml.
There were options added to clean the dct in the editor, but I can’t remember when that was added, and it works fairly well.
The export/import has improved and is reliable, but again not sure of your older version.
In my opinion it is reliable, but finicky. A few years ago now I wrote a program that would read a dictionary (via the DCTX) into an Oracle schema, you could modify things in the Oracle schema and then export back to a DCT (via DCTX). I intended to modify it to use SQLite as the backend, but got too busy/lost interest. Part of the problem was that Oracle has some nice built-in tools for reading XML, which I had used, and ditching Oracle you then also have to use another method to read in/write out the XML. I think I was also using an Oracle method to create new GUIDs for elements I added.
Finicky in the sense that sometimes the order of the attributes in a node matter, sometimes they don’t, and that if you run into a problem (for example, a GUID referenced in the Relations section doesn’t exist earlier (table GUI, Key GUID, column GUID)) then the import will fail and you won’t get much in the way of help as to where the problem is.
So, personally, I think trying to modify the actual DCTX XML would likely be a very frustrating exercise, not because the import and export is “unreliable”, but because it (the import process in particular) insists on things being exactly as it expects them to be, and you will only know that you have violated a rule when it refuses to import your modified DCTX.
I do vaguely remember that there were some not-often-used parts of the dictionary that don’t get exported into a DCTX. IIRC it was a problem that Lee ran into?
I think there is some shared code between importing a DCTX and the Synchronizer importing stuff from other sources. What I seem to remember being a problem was that if, for example, you had a table called People that had columns house_colour and car_colour that both had to be found in the Colours table, that the import would decide it had to create an alias for the People table (rather than for the Colours table). So I think when you import the DCTX that you can maybe run into that sort of WTF. [I’m sure it used to be a problem with multi-table imports, just cannot remember if it was fixed in general, or whether it really was a problem with DCTX imports].
A couple of other comments. There is a bug in versions prior to 11.1.13845 where user options attached to columns/fields in your tables could move from one field to another on export to DCTX.
If you export to TXD instead and want to import back in to the dictionary, you need to export any APPs that use the DCT to TXA format and re-import them. Importing an APP from TXA matches fields to the dictionary based on Name, not the IDENTs. If you don’t, then the APP will get confused.
Thank you so much for all your replies. You’re helping me understand what’s going on.
As JonW said and as I’m finding out, the best definition for the dctx export/import is not “unreliable”, but “finicky”.
To understand a little better what’s going on, I tried to compare the original source code generated for the main dll (the one that contains all the declarations of the dictionary related stuff) with the same source files generated after the dctx export/import, and there are a lot of differences. I’m examining all those differences and, till now, all of them are related to errors or inaccuracies contained in the original DCT. It seems that the export/import procedure is simply trying to fix those latent problems.
Till now I found problems or differences in table relations (and I discovered that we have various malformed relations) and in field validations.
We are realizing that our dictionary needs a thorough overhaul.
Moreover we have to decide if we want to spend time to upgrade from Clarion 10 to Clarion 12 to avoid the problem Rick is talking about. We should…