ADM2 - DB Name in SDO

In SDOs, appBuilder places the DBName as prefix to tablename. Is there a way to avoid that?

The AppBuilder should only qualify tablenames with DBname if you check the "Qualify Database Field with a Database Name" in the AppBuilder Preferences, which you find on the Options menu. Note that this setting applies to compiled/runtime code. The generated code always has a database reference in various comment sections in the source code that are used by the AppBuilder at design time and you will get "question" messages when you open this SDO in the AppBuilder when connected to a differently named database. You should still be able to open the file if you choose the continue options of the "question" messages.

We dont see any other option except to re-write them.

If you actually did generate the SDOs with the  "Qualify Database Field with a Database Name" set to true then you need to turn this option off, reopen and resave the SDOs. This might be quite cumbersome, but you should not need to re-write the SDOs. (It is possible to write code that does this using the AppBuilder API)  Any manually written code that has database qualifications will of course  need to be fixed manually.

Is there a way to use SDO create with dataybase name "Sports" but same database is now connected with logical name of "Sports2000". DB-Aliases seems to be an option but any other suggestions would be welcomed.

I think the simplest way to resolve this is to use an alias:   create alias sports for database sports2000.

What happened that made it necessary to use a different logical name?

Havard,

Thanks for the reply.

We had actually set that flag to FALSE (sorry for not mentioning it earlier). Appbuilder indeed adds DB name in the source file (not sure of .R-code though). When we tried opening the SDO file in appBuilder with renamed DB, it gave a warning message as you mentioned. On choose of continue button and saving the file subsequently, it actually corrupted the SDO file. The file size was reduced to 6K from 40K. All the internal procedures and functions were lost.

We tried to be smart and opened SDO file in procedure editor, replaced the old DB name with the new one. Progress was even smarter and removed the SDO icon shown on SDO file in the desin mode. In this case, all internal procedure and functions were there but query and tablename, fieldname were gone. We repeated both the above activities several times but still had the same issue.

What I am actually failed to understand is that sdo.w is a 4GL file. After changing the DB name including in the comments portion, how come it still remembered the old DBname? I even removed .R code before trying opening this changed file in appBuilder.

Thanks

Vishwdeep    

We had actually set that flag to FALSE (sorry for not mentioning it earlier).

Your SDOs should compile when connected with the new logical name then. R-code that was compiled against the old logical name will need to be recompiled against the new logical name.

Appbuilder indeed adds DB name in the source file (not sure of .R-code though). When we tried opening the SDO file in appBuilder with renamed DB, it gave a warning message as you mentioned. On choose of continue button and saving the file subsequently, it actually corrupted the SDO file. The file size was reduced to 6K from 40K. All the internal procedures and functions were lost.     

According to my understanding this should not happen if the database is exactly the same, but I also know that there are unresolved issues in this area. I strongly suggest that you contact Support to check if this is a known or new issue and to get the most current workaround information.

We tried to be smart and opened SDO file in procedure editor, replaced the old DB name with the new one. Progress was even smarter  and removed the SDO icon shown on SDO file in the desin mode. In this case, all internal procedure and functions were there but query and tablename, fieldname were gone. We repeated both the above activities several times but still had the same issue.
What I am actually failed to understand is that sdo.w is a 4GL file. After changing the DB name including in the comments portion, how come it still remembered the old DBname? I even removed .R code before trying opening this changed file in appBuilder.

The design time information is derived only from the generated source code and I would have suggested this as a workaround. I've done this quite often, but mostly with simple code (bug duplicatons and such), and it is very easy to miss something in the source code (even with search /replace).

Thanks Havard,

I understand rowObject is a client side procedure. Are you sure rowObjUpd is available in rowObjectValidate procedure in real appServer environment? I have not setup the appServer stateless environment yet and hence could not test. But our deployment would be appserver with remote connection.

Thanks in advance.

Vishwdeep

rowObject is a temp-table not a procedure.  rowObject carries you data between client and server.  There is usually 2 copies of your data for each changed record. The record with rowmod = '' had the original values while rowmod > '' had the record with the changed values.  It will be available however you run.  The adm2 server internal procedures also have equivalent temp-table records but they are named rowObjUpd, however rormod remains unchanged.

Trust Havard, as he is the man as far as ADM2 goes.

Miles

Thanks.