Developing the back-end

[Nimh]

Hello everyone,

So I've learned the basics of splitting database into back-end and front-end, but could not understand how to continue developing the back-end.

My users use queries and forms which are based on FE queries which are based on BE tables. But in this scenario respective BE table got locked and I can't perform any changes to its design. Well, I understand the reasons, but how can I continue developing BE without asking all users to close FE? Can't perform compress and repair or overwrite BE file with new BE which I changed and used for testing for example.

How do you keep developing BE once your DB is split and in production?

 

[CJ_London]

The same way as if you hadn't split the db - if you are making changes to the tables the users need to be off the system. Once the db has been designed the back end should not require changes.

However, not tested but it could be that depending on the change and whether users are accessing a table when you want to make a change to it you could try using SQL to add/change/delete tables and fields

Here is a link to alter a table to get you started, browse the site for more options

http://www.w3schools.com/sql/sql_alter.asp

You can write the queries in the back end, but you'll need to test in your environment to see if it works

 

[vbaInet]

An important point is that you should not be developing on the live/production database. Development should be done on a copy of the live database.

 

[gemma-the-husky]

The only thing you should need to do with a back end in general is to add new tables, fields, indexes etc. In any dbs, you cant change these with a table that is in use, so while such changes such changes are made you need users to be out of the dubs briefly.

 

[Tophan]

Hi, I've been reading this and similar threads regarding putting a password on the backend of a database. I just need some clarification on a few issues.

My DB is not complete yet, if I were to go-ahead and split the database, any changes to tables needs to be done in the backend? Is this correct?

If I want to make a copy of the DB as a backup, do I need to copy the backend too or does this automatically serve as the tables backup?

Finally, I tried splitting and adding a password on a copy of the DB; I noticed however that on clicking the linked tables a message pops up saying something like the tables need to be accessed from source and then it asks if you still want to open the tables? Is it because the backend is set to open exclusively that I can still open the source tables?

Looking forward to your response

 

[vbaInet]

Tophan, your questions aren't completely directly related to this thread because the main point of the thread is "How do you keep developing BE once your DB is split and in production?". You should created your own thread.

My DB is not complete yet, if I were to go-ahead and split the database, any changes to tables needs to be done in the backend? Is this correct?

Any changes/development need to be done on a copy (i.e. test/development copy) of your database. Once the changes have been fully tested and proven you make adapt your live database to reflect the changes. You do this when all your users are logged out.

If I want to make a copy of the DB as a backup, do I need to copy the backend too or does this automatically serve as the tables backup?

The backend holds all your data. That's the most important part to backup. You should already have copies of your front end.

Is it because the backend is set to open exclusively that I can still open the source tables?

That message is asking you to re-connect the tables to the back end.

 

[Tophan]

Thanks...sorry for posting in the wrong area.

 

[exaccess]

The first commandment when developing an application is to keep the development and operational environments separate. When you do that you never have such problems. The second commandment is to keep the programs ie modules, forms. macros, queries, reports separate from tables. This is why we split the databases so that the two groups are completely apart. If we have to restructure tables then we do it on the test system. When all is debugged then when nobody is on the system we replace the front ends and we restructure the backend carefully backing up first the operational data and then loading it into new tables. I hope this small paragraph based on years of field experience helps.

 

[Tophan]

Thanks. I've been trouble-shooting the database myself for about a month now and was just doing some minor formatting this week. I want to provide a copy for some possible users in the office to try and give me their feedback before I split the database.

Thanks for the advice...it is really appreciated.

 

[vbaInet]

If we have to restructure tables then we do it on the test system.

If you want to do things properly you shouldn't be designing on your test system. You should have a Design database and a Test database... as the name goes.

 

[vbaInet]

I want to provide a copy for some possible users in the office to try and give me their feedback before I split the database.

Still split your database even though it means carrying two files with you. I hope this is just for feedback purposes and not as a test routine.

 

[exaccess]

If you want to do things properly you shouldn't be designing on your test system. You should have a Design database and a Test database... as the name goes.

Well this is a matter of terminology. Essentially there are two environments:
1. Where you do your design, testing, development, etc ie everything in the IT shop hidden from the user, if I may call it that way.
2. Where the actual users and live data are, that is the operational environment.
Here by saying test database I meant the first one. Sorry if I caused any misunderstanding.

 

[vbaInet]

Well this is a matter of terminology. Essentially there are two environments:
1. Where you do your design, testing, development, etc ie everything in the IT shop hidden from the user, if I may call it that way.
2. Where the actual users and live data are, that is the operational environment.
Here by saying test database I meant the first one. Sorry if I caused any misunderstanding.

Three environments: design, test, production. You don't mix design and test.

 

[exaccess]

Three environments: design, test, production. You don't mix design and test.

Well I think we are going out of the limits of this thread. This can be the subject of a separate discussion.