OPTION A: You know the many benefits of a split-database architecture including data-safety, upgradability, front-end options, concurrency, etc. And while not inherently portable, a Base front-end file (.odb) may be macro-enhanced to provide sufficient portability, such as when adopting a portable Base template.arfgh wrote:...i have tried to inverse the way to embed again the files, and for some reason i cant edit the database files....
why ?
OPTION B: You know that an embedded-file database has an advantage or two, such as inherent portability and ease of modifying existing field-attributes using the Base GUI. But you also know that Base is buggy and incapable of reliably hosting database files embedded within the .odb container file -- leading to rampant data-corruption, among other drawbacks of the proprietary design.
Weighing the options, you chose to convert to a split-database architecture. This is common and recommended.
Now you're realizing that modification of an existing field attribute with a split architecture involves selecting an SQL command -- perhaps among those provided by F3K Total and Villeroy above -- and typing it into the Tools > SQL console in Base. This not only requires 60 seconds of effort, but it's understandably uncomfortable because SQL is an unfamiliar language. Knowing that SQL is easily generated by a GUI, and that you may encounter an additional episode or two involving modification of existing field-attributes, you seek GUI relief. But then, it's not worth 100 bucks simply to avoid these rare instances of pain. After all, that's $100 simply to avoid a few minutes of discomfort over the life of the database -- not to mention the setup required to connect another front-end to your database.
So you're concluding that it would be better to revert back to an embedded-file database. I'm sorry but I don't think you'll find many folks here willing to spend the time to outline the steps or perform the procedure simply to alleviate those rare minutes of pain in this case.