Book a Demo

Author Topic: DDL vs Code  (Read 3708 times)

Thomas Mercer-Hursh

  • EA User
  • **
  • Posts: 386
  • Karma: +0/-0
  • Computing Integrity
    • View Profile
DDL vs Code
« on: December 12, 2007, 12:36:34 pm »
I notice in the standard datatypes that there is a distinction made between DDL and Code.  Presumably, this is because Oracle, for example, is a database, but not a language and because Java and C# are languages, not databases.  Would I be correct in assuming that in the case of OpenEdge, which is both a database and a language with the same datatypes, that I should define two identical sets?

Anyone know the significance of PDATA4?  


«Midnight»

  • EA Guru
  • *****
  • Posts: 5651
  • Karma: +0/-0
  • That nice Mister Grey
    • View Profile
Re: DDL vs Code
« Reply #1 on: December 12, 2007, 01:29:24 pm »
Thomas,

I think that is probably correct way to go.

If I were to build a FoxPro facility for EA, I'd define the data types and language types differently, even though they are based on the same engine.

David
No, you can't have it!

Thomas Mercer-Hursh

  • EA User
  • **
  • Posts: 386
  • Karma: +0/-0
  • Computing Integrity
    • View Profile
Re: DDL vs Code
« Reply #2 on: December 12, 2007, 01:40:37 pm »
Another question:

t_datatype has no GUID, just datatypeid.  If one is making a package to import datatypes, is there any problem just starting at some high number like 1000 for these IDs, i.e., is EA going to mind if there is a gap?  I.e., I have exported the full set of datatypes and I'm going to edit this down to my additions and then provide it to others to load datatypes.


Thomas Mercer-Hursh

  • EA User
  • **
  • Posts: 386
  • Karma: +0/-0
  • Computing Integrity
    • View Profile
Re: DDL vs Code
« Reply #3 on: December 12, 2007, 01:41:56 pm »
In what way would you define the datatypes differently for code and DDL?  Is this some peculiarity of FoxPro where they have different behaviors?

Thomas Mercer-Hursh

  • EA User
  • **
  • Posts: 386
  • Karma: +0/-0
  • Computing Integrity
    • View Profile
Re: DDL vs Code
« Reply #4 on: December 12, 2007, 04:39:31 pm »
Of course, haven't gotten into it, I now realize that, of course, ABL has datatypes in code which do not exist in the database, e.g., HANDLE, so clearly they are different.

But, more questions ... for the following properties

MaxLen
MaxPrec
MaxScale
DefaultLen
DefaultPrec
DefaultScale

It seems that they are defined with meaningful values when they apply, but when they don't apply they are sometimes defined as 0 and sometimes left as null.  E.g., for a character datatype, concepts like precision and scale do not apply.  Is it more appropriate to leave these null or to make them zero.  Examples are inconsistent.

Thomas Mercer-Hursh

  • EA User
  • **
  • Posts: 386
  • Karma: +0/-0
  • Computing Integrity
    • View Profile
Re: DDL vs Code
« Reply #5 on: December 13, 2007, 11:51:05 am »
And, while I am asking apparently unanswerable questions, what about GenericType?  From the name, I would have thought this was a mapping onto a set of primitives or non-language or DB specific generic types, but in several of the examples the generic type seems to correspond to the actual type in that particular language or DB, i.e., varchar is varchar, varbinary is varbinary, uniqueidentifier is uniqueidentifier .  This seems to have little information value!  So, what is good practice here?