We created a new table in the logan database and did a blddbdict and a dbreorg. However the table did not get created in the database (SQL server). I noticed the database space is set to "EMPTY" for logan.
What do I need to do to get the dbreorg to create this table in the database?

Any ideas?

I know I know, I am over posting today. :lala:

Okay it took me an entire day but I got it!!!!!!
And I learned how to fix just about every problem with reorgs at the same time.

So to add a table to logan in 9.0:

You'll notice that your data space for LOGAN is set to EMPTY.
BUT if you go to the "C. Data Areas/Data IDs" (F6 C) in dbdef for Logan
and the hit F6+B for "B. File Sizes And Database Space" you'll see a list of the tables in there which are each assigned to a non-empty database space.

MAKE SURE YOU TABLE IS ASSIGNED TO A NON-EMPTY SPACE BEFORE YOU DO A blddbdict and dbreorg. Otherwise you're going to have a long long day.

If you happen to miss that step. you'll have to remove the table, readd it again and you follow the directions as shown above.

If in the meantime you happen to create the table and your reorg says:

then you'll need to drop the table before continuing.

Bottom line is, tables cannot be assigned to EMPTY spaces and be expected to work or reorg properly.

Now why is there even such a thing as an empty space? You got me.

Ahh.. But EMPTY dbspace is a valuable asset. Assume you have some tables that NEVER have data in them, but your programs are regularly accessing those tables. Each access incurs a certain amount of overhead as a stream is opened to the DB and the table is read - often millions of times - only to return NO DATA.

But, if said tables are defined in an EMPTY dbspace, then the program automatically returns NO DATA without incurring the DB access overhead.

I just whacked 13.5 hours off of my current client's conversion programs today by defining 2 tables in EMPTY

CAVEAT: You cannot - under any circumstances - attempt to write data to a table defined in an EMPTY dbspace. The program *WILL* fail.

Sorry Dave, maybe you could give me an example of why you would write a program that would access a table that you know you would get no data for in return. Why even make the call against a table like this?

Or are you saying that these are just out-dated tables or something?

Tan:

I tried what you said you did in our 8.0.3 environment, but it didn't work the same. 9.0 must be updated. All I saw was configuration info that actually works properly only for Oracle.

BTW: When you already have a file defined [properly] in SQL Server, and you just want to add it to the metamodel via dbreorg, that's what the "-d" option is for. I've also learned the hard way, those SQL Server error messages are frighteningly familiar!

Very interesting & I'll watch for more updates.
In 8.0.3, there is no such concept of "EMPTY". If the table has to exist in third party database, then there must be non "EMPTY" value assigned in dbdef using F6->C option.

In 9.0, the "EMPTY" is created because of the method by which the LOGAN tables are created in the third party database during LSFCT installation.

Is this an issue in the system where the tables being created as "EMPTY" in dbdef automatically.

EMPTY certainly *IS* available as an option on 803 systems.
dbdef -> F6 E. Database Space -> Type I. Empty

Then you can assign your table to it in
dbdef -> F6 C. Data Areas and Data IDs -> F6 B. File Sizes and Database Space

And it works great as a repository for those tables that will NEVER contain any data.

Tan, I don't think anyone would intentionally write a program that would access a table that is always empty, but in the Lawson system there are tables that are only loaded with data if you have option "X" or condition "Y" exists, or you purchased System Code "Z". Therefore Lawson programs must access them "just in case". It's finding and redefining these tables into EMPTY that can save you some (and sometimes a LOT) of processing time.

Note that this is a activity not to be undertaken lightly, because if you mis-define a table as EMPTY and you try to right to it the program WILL fail.

Oh!!! This is a news to me. I was under the impression that tables under this type belongs to flat file. So this means the physical files does exists in form of ASCII or plain text file or binary format under $LADBDIR/<PL> directory.

No Ganesh. It means the file(table) does not exist at all, but simply as an entry in GEN that automatically returns "No Data" when it's queried. EMPTY meaning that it's contains nothing and never will - at least so long as it's defined in an EMPTY dbspace

Dave:

Thank you for the extremely explicit explanation. I too was not "getting" it. Now I've got it! All of those tables in our Lawson installation that always have 0 records in them, and aren't used for temporary storage -- if they were to be put into "EMPTY" then the system could run faster. Hmmmm.

Ahhhh You *DO* get it! Your apps will run faster if those tables are at any time accessed during the program run. You'll save the overhead of actually attaching to the DB and trying to extract non-existant data.

Remember however, that selecting those tables requires careful analysis. If you have a table in EMPTY and anything tries to write to it, the program WILL fail.

I use the Lawson "timestats" function and analyze_stats utility to tell me what is going on inside the programs. You can find the docs for those functions/utilities in your Enterprise DB Administration manuals.