PDA

View Full Version : Feature request Output DEF files from Studio Table Editor



wila
14-Apr-2015, 04:45 AM
Hi,

Yes I am aware that DEF files are considered legacy and that this seems like a strange request, so let me explain.

For database changes while working in a team it is convenient to track those changes in a source control system. This gets more important when you work with developers in remote locations that have their own local database setup.

Assuming you use the embedded database checking in the database files itself is not really an option as the database changes all the time and is considered binary data.
If you use an SQL backend then checking in the INT files helps a bit, but isn't giving you all you need to know.

Enter .DEF files, yes they are pretty neat still!
If somebody changes a file, simply output the .DEF file and "voila" there you go, you not only see the file has changed (like .FD/.TAG might tip you) you also see what has changed.

Right now you have to go to a different tool, the "Database Builder" to let others know you made a change.
Can we please get this functionality in the Table Editor?

thanks!
--
Wil

Garret Mott
14-Apr-2015, 05:53 AM
Hi Wil -

Michale Mullen put something together for the tools menu: http://support.dataaccess.com/Forums/showthread.php?42678-Automatic-Output-of-DEF-amp-FD-files&highlight=output+def

Of course it'd be nice to have def's updated to SQL file types, etc....

Clive Richmond
14-Apr-2015, 09:09 AM
Hi Wil,

And following for Garret's reference here is another post (http://support.dataaccess.com/Forums/showthread.php?52731-SQL-datatypes-and-DEF-files).

wila
14-Apr-2015, 04:39 PM
Thanks guys. I'm aware of those posts and the workarounds.

While they are functional workarounds they require additional steps and need not to be forgotten in the work flow (which is what eventually will happen and then sit and eat time)

I'm also fine if the studio had more scripting hooks (yes another topic that has been on here before) like the ability to call a script or app after a table change (just need to be able to pass the filelist number can do everything else myself).
Unfortunately there are no hooks.. so I ask for please "let us output the DEF".

Would also be happy if they open sourced the Studio then also could add this by our self.. yep "never going to happen"
At least I got it off my chest.

Wait another few months and the topic on missing out on DEF files will be here again :D
--
Wil

raveens
14-Apr-2015, 11:22 PM
+1

Focus
15-Apr-2015, 02:07 AM
There is an open source version of electos so if it did happen it wouldnt be without precedent

Garret Mott
15-Apr-2015, 06:06 AM
Het Wil -

I agree that regular DEF output would be a good thing! Even a button that fired the dialog used in DBBuilder would be an improvement.

chuckatkinson
15-Apr-2015, 06:22 AM
A fix I would like in the .DEF is to make sure the "new-ish" longer field names are output. Currently they are truncated.

Stephen W. Meeley
15-Apr-2015, 07:49 AM
Wil,

I'm just thinking out-loud here, so don't hold me to anything.

The issue we have with DEF files are that they really had two uses - as documentation of the table structure but then as a way to recreate the table. It is mainly the latter use that we'd rather not promote continued dependence on. But in your scenario, you seem to really only want the primary use of documentation. If we were to consider having the Studio output table structure "documentation" (that might not even look like the current DEF files) would that fill your needs - or are you really looking for the entire DEF capabilities?

Garret Mott
15-Apr-2015, 08:43 AM
I'm not Wil (but you knew that).

I find the "create the table" functionality very helpful & use it regularly between developers: "Hey - I added this table @ # 816 - here's the DEF". I use them to load both embedded & SQL tables with little issue - though occasionally a column need tweaking, but that's easier than creating the whole table manually.

Peter van Mil
15-Apr-2015, 08:49 AM
Hi Stephen,

I am not Wil, but I have asked fro something similar before (see post (http://support.dataaccess.com/Forums/showthread.php?52731-SQL-datatypes-and-DEF-files)).

I never use DEF for the recreation of tables. I use it as the primairy source for documentation during development. DEF files can be opened quickly in the Studio and you can copy field names easily. For me structure "documentation" is ok. There are advantages to have it in plain ASCII. An option to have it in PDF too, would be nice.

DaveR
15-Apr-2015, 09:11 AM
I'm not Wil (but you knew that).

I find the "create the table" functionality very helpful & use it regularly between developers: "Hey - I added this table @ # 816 - here's the DEF". I use them to load both embedded & SQL tables with little issue - though occasionally a column need tweaking, but that's easier than creating the whole table manually.


I'm in broad agreement with this but I'd rather the DEF (or whatever) was output automatically on a db change. Again, mostly, source control, rather than communication

Clive Richmond
15-Apr-2015, 09:54 AM
Hi Stephen,


The issue we have with DEF files are that they really had two uses - as documentation of the table structure but then as a way to recreate the table.

Yes unfortunately they do.

From a personal point of view we're only interested in the documentation side as I highlighted in my reply here. (http://support.dataaccess.com/Forums/showthread.php?52731-SQL-datatypes-and-DEF-files&p=271154#post271154) I still like the idea of a legacy mode which would keep the status quo, for those who need it, and let others move forward.

seanyboy
15-Apr-2015, 11:04 AM
I have customers that use .DEF files to create and update files.
It wouldn't be the end of the world, but I'd rather not lose this functionality.

Stephen W. Meeley
15-Apr-2015, 01:29 PM
Sean,

I'm not talking about removing .defs from DataBase Builder at all - it's a legacy capability and, as such, can remain there. I'm only discussing the possibility of introducing a new kind of "structure documentation" into the Studio to address the specific need defined in the original message. Again, this is all just spit-balling at this point, no plans are in place (and certainly not for 18.1).

Garret Mott
15-Apr-2015, 02:05 PM
8789

Michael Mullan
15-Apr-2015, 02:08 PM
But of course you went there...

Michael Mullan
15-Apr-2015, 02:12 PM
well if you're spitballing a possible future enhancement for DocuDefs I'd like to request a 140 char comment field on each column, and on the table itself, that we can use to keep notes on the content and purpose of the various columns. Would be very handy to be used in auto generating People friendly documentation.

Could also be pushed/pulled to the Back end if SQL db happens to support it.

:-)

Yay YAFR!

wila
15-Apr-2015, 03:23 PM
Hi Stephen,

Talking about possibilities isn't committing yourself to anything as far as I am concerned.

You are correct, documentation purposes only. If we want to sync databases, add tables etc.. then there are a number of ways on doing that. This is for noticing that something has changed and for seeing what has changed. Acting upon that is only a 2nd step and I'm fine with that not being a feature in the Studio.

The DEF's work OK for this purpose, they are not completely ideal because creation date/time and # of records used in the file may trigger a "false" positive, but as the .DEFs are only written on a structural change that is do-able.

Personally I would prefer to have/keep a human readable -easy to compare- text format.
The DEF's are actually surprisingly good for that.
XML would be a big step down for me as that would require to write a specific compare tool to get it back into a human readable format.

thanks
--
Wil

Garret Mott
15-Apr-2015, 04:03 PM
You didn't say "I am Wil"... ;)

While an extra step, I posted code on the forum that produces what I call a "clean def" - that can be compared. It makes a copy of each def in the folder, cleans it up & gives it an extension of "cdef".

raveens
15-Apr-2015, 04:29 PM
Hi Stephen,

We mainly use DEFs for documentation (quick & easy) and version comparison; BUT we also use DEF to dynamically create (dataflex) tables at runtime - these are temporary tables for reporting and are disposed off after. Although saying this, I see less use of this method as we move towards DataFlex Reports (DR).

Another use we found useful with DEF (as with Garret), is the ability to "Copy" table structure from one development environment to another. We currently deploy using DB2 as standard, but have a DATAFLEX deployment too! And in the near future possibly MSSQL - therefore a single version will have 2-3 datasets .Currently, if a table is created in the DB2 environment (our standard development environment), we just use the DEF file to create the same table in the dataflex environment - just need to modify the Max records, driver name and locking - beats having to manually create the table from scratch. Yes! The database builder provides such a tool but what if you're creating a MSSQL table based on a DB2 Table?

As far as creating a SQL table from a SQL DEF, the ONLY thing that really stops it is the value of "MAX NUMBER OF RECORDS" - the LOAD_DEF and Structure_Copy command are checking it for a maximum of 16711679 - which is the documented maximum number of records supports by a dataflex table, wherelse SQL Defs have a maximum record of 2147483647. See original post (http://support.dataaccess.com/Forums/showthread.php?3644-Bad-attribute-value-lt-lt-STATUS-4097-gt-gt) back in Oct-2008.

Well, that's how we use DEF files and we feel it is still relevant.

Thanks

P/s: Its always good to have a healthy discussion about things. :)

Jim Albright
16-Apr-2015, 10:57 AM
+1

Mark Powers
20-Apr-2015, 09:55 AM
+1

Peter Crook
21-Apr-2015, 05:17 AM
I don't use .DEF files but I do find myself having to create .FD files for all tables, particularly when working with table changes from within the application, so the ability to do this from within the Studio would be helpful.