When we translate QA database file to Sesame- Application, Database and main form are given the same name, the same as QA database name. As such in Sesame all three could have different names. Database presents itself as a folder in which forms are located. One application can have multiple databases and one database can have multiple forms. If you wish to have a subform, the related databases should be in the same application. Sesame also gives you a tool to merge applications if one needs. This is my broad understanding.

I have about thirty different database files in QA that interacts with each other by X-family functions and make an office management system. What are the advantages of merging the applications?  If you want to open a form within a form using @SelectTreeItem, it assumes that both items belong to the same application (on the same existing tree displayed on the left)  and that would limit your interaction if you choose to keep all different QA database files as separate applications. But on the other hand if you merge the applications, the tree becomes very big and chaotic.  Does it change any programming syntax if I choose to keep all of them as separate applications? Sorry for my disjointed thoughts and rambling but I am thinking as I write.

I would like to have feedback as to how to structure a system (a little broader term than Sesame Application). Should I merge applications? Should I keep them separate?

Bharat,

This is an excellent question which requires more than a quick two sentence answer.  Your question covers a level of general system design decision that applies to any database management program, not just Sesame.

Give us a liitle time to write up a good and thorough answer for you and for others who may have the same question.

Thank you very much for your feedback.  More discussion and brain-storming on this topic will be helpful to many people using Sesame. 

If one merges databases, I believe, it becomes bigger and more complex application. How does it affect the recovery of database and data in case of corruption? Unfortunate database corruption is the fact of life. Question is not if but when? And at this time  backup is the only means of protection we have. I might be putting cart before the horse here but then well thought out planning and sound foundation is essential for developing any data management system.