Once again .. oi crapped out during the creation of an index .. we use pointers instead of the dbt and got the same old error .. x:\sdf\asdf same as app_datavol .. blah blah blah

Would it be possible to have this fixed at some time?

And if OI is not as smart as Arev with pntrs would it be possible to atleast have th 'create index' process not screw up .. once again the dict has been changed but no !file created .. so the dbmgr index create shows that there is an index .. but the rebuild does not show it ..

Please .. i asked for indexing to be beefed up for quite a while .. this is a FUNDAMENTAL part of the data base .. so FIX IT

thanks

dsig

dSig,

You complain that adding indexes in OI frequently fails because of .DBT handling. Have you looked at the index build/rebuild utility and multi-database volume management in ATLAS? I am using .DBT files, and I do not encounter the problems you ascribe to OI.

"Would it be possible to have this fixed at some time?"

Revelation Software is faced with no easy solutions for changing the Database Manager, and I haven't seen anyone put forward what I would consider a working proposal for addressing its shortcomings. If you know what to do here, become part of the solution.

Meanwhile, I recognize that I do not get positive attention from Revelation Software when I throw a hissy, which is why I try to avoid that behavior pattern (at least on-line).

Gerald

oh man .. thanks ..

I would like to discuss the database manager just a bit.

I don't see why the linear hashed data files need to be "database managed". Although I could be "not" considering some reasoning, and maybe some form of necessity… Why not just "point" to the path of the linear hashed file.

See, moving a file (or table) from one application to another, or even having multiple "volumes" would be so much easier.

I would assume that there is some need to control "runtime", so that is is not able to move files around or access this flexibility.

Honestly… if I had the time, I would create an MFS or BFS to bypass the database manager and use a "pointer" method for accessing linear hashed files.

Richard,

The Database Manager works pretty good for development. When you open an application you want the same set of files always attached. In a runtime this doesn't always hold true. In fact, when I deploy a runtime I purposely update the Database to not have any meaningful tables attached (except Datavol and Revboot). Then when the user logs in a startup routine reads an ini file and attaches the correct volumes.

John

Richard,

I use the .DBT file image concept in OI, but I ignore the DB Manager. The file image concept has the following strengths: (1) rules for file attaches may be set in data definitions, (2) temporary file attaches or assignments are avoided at startup, (3) startup and volume switching are much faster operations.

Since DB Manager does not support multiple data volumes, I have my own manager program which builds a .DBT image for each volume automatically. I also have volume create routines, mfs installation routines, and index maintenance routines. When an mfs is installed or an index is changed, the .DBT for the target volume is deleted and recreated from the attach definition.

Index maintenance is a special subject. I support metaphonic name indexing, which is an extension to OI indexing, so I have my own index installer. My installer can add or remove Quickdexes and Rightdexes on data files and dictionaries as well. When a GFE occurs in an index file, my index rebuild routine will clear the index file, reestablish the index control information based on the data dictionary, and then force a build of all indexes. OI does not offer a complete index management utility like this.

I also have a CONTROLS table which includes records which list data volumes for the current application, and which list the attach commands to execute before creating the .DBT. I specify the attach commands to execute, rather than the volumes to point to, so that file inculsion/exclusion rules may be implemented.

A rewrite of DB Manager could store equivalent CONTROLS information in the Repository, and support for multiple data volumes could be added. I would be happy to consult with Revelation Software on this if it were a priority for them (but why would it be?). Alternatively, developers are welcome to use the ATLAS features for extending DB Manager. In fact, I would be delighted for someone to examine these utilities.

Gerald

yep .. volume pointers ..

the problem with dbt is it hardcodes the locations which is not very object like ..

There is no reason that any physical locations should be known to the system ..

oh heck .. i hope that wasn't a hissy fit .. oh my

DSig,

"There is no reason that any physical locations should be known to the system .."

I get your point from the programming standpoint but not from a systems view. If OI doesn't know where the files are located, then how does it access them? My perspective is that the .DBT encapsulates physical locations so that they are not addressed in programming. This is part of why I use .DBT instead of volume pointers when switching databases in an application. So are we saying the same thing?

Gerald

nope ..

Sig-

I'll be looking at the DM today and tomorrow. Is there a number I can reach you at today?

Thanks

Mike

Mike,

Looking at DB Manager, could you examine the possibility of adding multi-database volume support in an application via multiple .DBT images? I and many other developers would appreciate this feature. I know that database image name is @AppId, but using this is either unsupported or at least undocumented.

Thanks,

Gerald

Gerald-

I don't understand what you mean by multi database volume support.

Mike,

"I don't understand what you mean by multidatabase volume support."

Which could explain why it is not a feature…

I'll go for the longer version of the explanation. My WARES application customers frequently run multiple businesses on a single application package. They use my "Create Volume" utility to copy a default "W_DEMO" volume to a new directory and empty the data files. This also creates an image as "volume.DBT" (W_DEMO.DBT, e.g.). Then they set up a new company, or a building, or whatever they want to put into that dataset. They use my "Access" feature to switch logins from one volume to another.

The Access feature calls my Manage_Dbt program, which OsReads the .DBT image for that volume and OsWrites it to the WARES.DBT file. Then the WARES.DBT image is loaded to perform the volume switch. This works in general, but I might prefer not to do the file copy, as this introduces potential issues with multi-user. (What if two users switch at the same time? What if an image is corrupted in the copy? etc.) I would prefer it if the DbManager could save an image to a named .DBT file, not just to the application name. If Swap_Database could load a named image, not just the "application.DBT" file, then much of the functionality in my Manage_Dbt would be subsumed by OI native routines.

This functionality of saving named images and loading named images existed in AREV, but somewhere along the way the reason for this got lost, I guess. However, this feature alone is one of the big advantages WARES has over its market competitors.

Anyway, thanks for giving me the chance to explain this.

Gerald

way cool .. 9715702005

View this thread on the Works forum...