TEMP-DB

Myself, I have never been very interested in this approach because I dislike the whole idea of having TT and PDS defined in multiple places.  If you are going to have them defined multiple places, then there isn't really any choice but to use an include file to provide the definition ... otherwise you end up doing duplicate maintenance on multiple pieces of duplicate code ... clearly dumb.  But, include files provide their own issues.  Far better is to encapsulate the TT or PDS in its own wrapper PP, SP, or .cls and do everything through an interface to that wrapper.

Thanks again.

Initially I had the set up idea of having an include file that had the definition of the temp-tables and the definition of the dataset.

However, when I put the include files into some of the WebClient GUIs I had duplicate definitions of the tables.

I then removed the temp-tables from the PreProcessor definitions to get over the compile problem.

This worked but then I couldn't re-open the files as there were GUI fields using the temp-tables from the PreProcessor.

There-in lies my problem.

The possible solutions I can see at the moment are as follows...

1. Remove the temp-tables from the PreProcessor definitions from all the GUIs and put them into my initial temp-table/dataset include files and change all of the GUI fields to use variables instead of temp-tables.  (Lots of rewriting but the best outcome for maintenance).

2. Add include files to each PreProcessor definition temp-table (like guie) allowing the editing of the temp-tables through their include files.  (Not as much rewriting but not good for maintenance).

3. Set up the TEMP-DB with the dataset temp-tables.  Change the PreProcessor temp-tables to use the TEMP-DB (allowing the GUI to remain unchanged).  (Least rewriting and temp-table definitions are all in one place and actually have a GUI to manage them but datasets are still separate from temp-tables).

Is there anything I have missed?

How does the wrapper idea you suggested work?

Thanks!

Both preprocessor directives and include files are essentially evil.  Take that as your starting point...

The encapsulation approach puts the TT or PDS inside a .p or .cls and provides all the needed logic within that wrapper to perform any needed operations.  I haven't paid a lot of attention to this for UI, since I haven't been focusing on ABL UI, but the principle should be the same.  It is really just an extension of the principle for designing objects... what happens inside the object is invisible to the outside and all that is visible is the methods and properties necessary for other objects to get their job done.  Really, this is no different than what we learned to do in 7.3 of putting different parts of a screen each into their own PP so that everything related to a particular tab or frame or whatever was inside that box.

What are the general views on using TEMP-DB stuff?  Is it something to look in to or avoid?

The AppBuilder (formely known as UIB) was designed long before temp-tables were part of the language and workfiles (the previous structure) were not that heavily used as temp-tables are today while designing distributes systems. This legacy requires that when designing UIs in the AppBuilder you need to have a database table containing the table definition. All the dialogs of the AppBuilder like the Query-Designer or field picker are designed to work against the schema of physical database tables. The same is valid for the source code parsing process when opening a .w file into the AppBuilder. The AppBuilder simply can't work with a schema of temp-tables when it's available only in source code.

So when working with the AppBuilder and a UI based on temp-tables (I'm not talking about ADM2 SmartDataObjects and the RowObject temp-table) using the temp-db is the solution to not depend on "abusing" the "real" database tables. By separating out the temp-table definitions to a separate database in theory this also gives a sort of abstraction between the "real" DB and the temp-table.s

The temp-db maintenance tool makes it easy to synchronize the temp-table definitions in include files (they are usually more handy when writing business logic) with the schema in the temp-db. So the actual source of the schema are the include files, and the temp-db is a projection (when using the maintenance tool).

So you may like it or not, but using the temp-db is a requirement for using the AppBuilder with temp-tables. The temp-db is not required at runtime, just at compile time and when working with the AppBuilder.

You made a comment about having the temp-table definition and the dataset in separate files. I see no problem with that. The same temp-table might be used in more then one dataset (two different instances of it), so having the DEFINE TEMP-TABLE statement separated from the DEFINE DATASET support that possibility. By the way: I believe there is no better place for the DEFINE TEMP-TABLE or DEFINE DATASET statement than in include file! Those definitions are usually (Thomas will probably disagree) shared between more than one compile unit, so it should be defined in an include file.

On the positive side, the new Visual Designer - when moving to GUI for .NET - does not rely on the temp-db for databinding at all :-) If you don't extend it's capabilities it relies on XML schema files that can be generated from temp-tables or datasets.

(BTW I have mentioned the mentoring/consultant thing to managers now and they all seem to be in agreement that it sounds like a good idea.  Who would I contact in getting a rough idea of how things work regarding this?)

Great - it's always good to have the management standing behind this. Generally speaking there are two options: Contact your local Progress office and ask for the services manager or contact an independent consultant or consulting organization that is active in your region (by the way, we are working with clients all over Europe and the UK directly or in cooperation with the regional Progress offices ).

At the beginning you should discuss with the candidate where you stand today, what are your main issues and challenges, what are the key factors of the existing application that you need to keep, where do you want to be in 6 month from now, a year, two years, etc... Choose a mentor that has a lot of experience with your current architecture and where you want to go and is able to help you building a vision with Progress' past, current and (possible) future in mind.

So you may like it or not, but using the temp-db is a requirement for using the AppBuilder with temp-tables. The temp-db is not required at runtime, just at compile time and when working with the AppBuilder.

Thanks.

This makes more sense.

So the program will compile with the temp table defined in an include file.

And at run time the GUI fields can access the data given in the temp tables (which are defined inside the include file).  But the AppBuilder can't parse the files without having the temp tables defined in the PreProcessor bit.

So do I need to define the temp-tables from the Temp-DB in the PreProcessor temp-tables bit or is calling them by name enough?  If so, how do I manage the run time error that the database TEMP-DB is not attached?

Thanks again for the help!

I'm learning at a ridiculous speed at the moment and things are beginning to get slightly clearer.

Oliver

Generally speaking there are two options: Contact your local Progress office and ask for the services manager or contact an independent consultant or consulting organization

Let me make a few remarks about these choices and see if I can keep from getting into trouble....

There are some people who assume that the professional services organization of their technology vendor is going to be the premium offering.  There are times when this is true, but there are also a lot of times when it is not.  Certainly, there are a number of Progress Application Partners who have a pretty terrible reputation for the services they provide.  I'm not sure why that is, since I would expect them to care, but there are many, many negative stories.  One of the contributing factors, in any size company, is that a professional services job is often a somewhat entry level position and someone who builds up an experience base doing this kind of work then goes off to find something more interesting to do.  That is far from universal, of course.  It can even be useful, if you get connected with a realy sharp core consultant to set direction, then some of those wet-behind-the ears types can help with the more routine work.  Of course, that might not be much help if you want to do most of the work yourself.  So, bottom line when dealing with larger organizations is to scruitinize the offering very carefully to make sure you are not getting a cookie-cutter, one-size-fits-all solution and that the people you personally are dealing with are of top quality.

Independents, naturally, vary from being the very best to less than stellar.  The very best tend to be independents because they can.  They are likely to have less manpower depth than a professional services organization, but unless you are contemplating sub-contracting a lot of work, that is probably irrelevant since what you need is direction, not coders.

At the beginning you should discuss with the candidate where you stand today, what are your main issues and challenges, what are the key factors of the existing application that you need to keep, where do you want to be in 6 month from now, a year, two years, etc... Choose a mentor that has a lot of experience with your current architecture and where you want to go and is able to help you building a vision with Progress' past, current and (possible) future in mind.

One thing I would like to add to this is that you should recognize that no one knows everything anymore.  In the 1980s, a person could pretend to be competant with the whole Progress product in most aspects, but we are long past this point.  This can mean that there is no superhuman who meets every aspect of what you might dream you want ... but sometimes the solution to that is to use more than one person.  A lot depends on what you have as resources in-house and where you really think you want to go.  I.e., if you are mostly thinking about tinkering with what you have, then you would certainly want someone who was knowledgeable about your existing way of working since they would then already be up to speed.  But, if you were thinking in terms of a significant realignment in OERA directions, you might want to emphasize finding someone with the vision to guide you to that future.  You might also find that you actually can use more than one person.  E.g., some people are performance experts, other people do architecture.  They don't have to be the same person.

One thing I highly recommend is paying attention to this aspect of where you want to be in the future ... not just 6 months from now and not just in terms of IT goals, but in terms of what is the busiiness requirement.  For that, you need someone who really understands business issues and broad technology choices and their impacts.  You certainly wouldn't be the first company that thought their IT needs and desires were very clear, but after stepping back and really analyzing business impact and future business plans, found out that the obvious wasn't all that important, but something else was.  As I mentioned in the other thread, business opportunity costs and business revenue potentials can easily dwarf any of the IT costs involved, so without that context, one is making a decision in the dark.

Thanks!

I've got it working now!

...well almost

Seems that the TEMP-DB maintenance thing can't accept certain datatypes as fields.

A couple that I have come across are ROWID and RAW,

(Not that I know what RAW is).

I don't know if these are essential fields but all I can do is not include them.

Hmm...

Whenever I try to run the program I now get an error because the Temp-DB isn't connected.

I have inserted the inclued files generated by the Temp-DB maintenance and it compiles fine.

I have checked that there are no references to the temp-db database and the only reference is a comment at the top of the file with a list of connected databases.

Hmm...

I've just restarted my PC (Windows updates) and now when I go back into AppBuilder I can't seem to access the TEMP-DB tables anymore.

It is connected and I can go into the T emp-DB maintenance etc... but when I try to add a database field the temp-db isn't there to choose.

Oh well.

ojfoggin schrieb:
Hmm...
Whenever I try to run the program I now get an error because the Temp-DB isn't connected.
I have inserted the inclued files generated by the Temp-DB maintenance and it compiles fine.
I have checked that there are no references to the temp-db database and the only reference is a comment at the top of the file with a list of connected databases.

A LIKE definition does not cause a dependecy on the database. Try

RCODE-INFO:FILE-NAME = "path/to/your/dotrfile.r" .
MESSAGE RCODE-INFO:DB-REFERENCES .

It should not include the TEMP-DB.

If it's the case, my guess is, that somewhere you are accessing a table from the temp-db because you are missing a LIKE definition somewhere. The temp-table has preference for the compiler where it has the same name as the database table and it has the same name.

ojfoggin schrieb:
Hmm...
I've just restarted my PC (Windows updates) and now when I go back into AppBuilder I can't seem to access the TEMP-DB tables anymore.
It is connected and I can go into the T emp-DB maintenance etc... but when I try to add a database field the temp-db isn't there to choose.
Oh well.

Can you see the tables in the data dictionary?

Are you shure you are connecting to the same temp-db now???

tamhas schrieb:
Independents, naturally, vary from being the very best to less than stellar.  The very best tend to be independents because they can.  They are likely to have less manpower depth than a professional services organization, but unless you are contemplating sub-contracting a lot of work, that is probably irrelevant since what you need is direction, not coders.

There are independent consultants and independent coders and there is a large network between them. So when there's a need for more manpower that can usually be accomplished.

Seems that the TEMP-DB maintenance thing can't accept certain datatypes as fields.
A couple that I have come across are ROWID and RAW,
(Not that I know what RAW is).
I don't know if these are essential fields but all I can do is not include them.

That's not good but not critical, you should report it to tech-support.

A ROWID is a pointer to a record. You should not try to have that in a temp-table anyway because only a Prorgess client will have that data-type. Other clients may represent this field as a byte[] or so. It's much better to include the unique of the underlying database record in the temp-table. That's more universal. A GIUD is a good canditate for unique keys.

A RAW is a small BLOB, unformatted binary data, but limited to 8k (or similar) in size.