Database Splitting - Any changes reqd?

[Blackshark]

Hi all,

Having built 101 smaller 1-15 user applications that dont need much upkeep, I am now producing a system that will require front end changes on a regular basis. I am therefore looking to use the DB splitter.

If I go and split the DB will I have to do anything different?

I mean this in a 'total' sense ie. coveringteh design of the forms, VB code (DAO) etc...

Thanks Tim

 

[Darrylles]

Hi Blackshark,

You seem to be 'splitting' your application because regular front-end changes are to be made. This is not a reason to split the application.

The reason to 'split' an Access application is because there are too many users to all share the front-end on the server (it is too slow).
Think about this, because version control can be a pain in the arse when having to copy changes to all clients.

If by 'splitting' the db - you mean taking the data tables out of the application and placing them say on a network, and then having the interface (front-end) sitting on numerous clients, then there are no changes to forms, reports, macros, code etc. etc.

Just to show that there are no changes.....

1)Backup the whole application.
2)Copy the whole application to a network drive.(For tidiness (and version integrity) you can delete all objects (forms, reports, macros etc.) barring the tables from the network copy). You can leave 'em if you want.
3)You will probably have a dedicated machine where you will be making the front-end changes. Copy the complete application to this machine.
Delete all data tables from this copy.
Produce database links in this copy to all tables which are on the network. These links are to all intents and purposes viewed as the original tables by Access - it therefore needs no amendments to any other objects.
4)Run your application from your development machine.
5)Copy this development version to all clients.
6)Done.

Sorry if I'm trying to teach my grandma to suck eggs, but... hints (from my past mistakes)....

a)If you're using NT server, then always place your data portion of the application in a SHARED directory, this means that if you change the folder's location to another drive - it'll be found automatically by all clients.
b)Think of a version control system for your application.
E.G. Always think of a logical 'cut-off' point for your application changes, make the changes, give it a version number - copy the application to a new name e.g MyDB_130502 in a common directory.
Have a notepad in that directory which gives a summary of changes made to each version. Distribute this version to clients.
c)Something that I do is: have an identical copy of the application that all clients have & no changes are made to this which ensures I can duplicate their problems.
I also have a FULL local application with a copy of the tables also in the local application. The data inevitably becomes out-of-date quickly, but development is much quicker (and I can change data without affecting the users). This is my development copy.

Sorry for the novel - hope it helps.

Darrylle







"Never argue with an idiot, he'll bring you down to his level - then beat you with experience."

 

[Blackshark]

Darrylle,

Thanks. My reasoning for wanting to strip out the data tables were so that I could have two front ends running with users updating one set of datatables.

Once the users were happy with the changes/updated version of the front end i can delete the prior version and wait until a new list of chanegs/additions are thought up.


Do you still think it unadvised to use the DB splitter?

Regards Tim

 

[Bry12345]

Shark,

I split db's all the time and don't really encounter any issues. I usually take it one step further and make the front end a .mde.

Two considerations:

With front ends on the client side, you may have to refresh the links to the back end on each computer .. .depending on mapping.

There MAY be some issues if the database is secured. Mine are not, so I haven't had to work through this issue. There have, however, been a number of security posts here regarding this. - - - -

Bry

 

[WildHare]

Actually, there are a couple of things you MAY have to check for (at least there were in A97, not sure about A2K and above)

1) the SEEK method does not work with linked tables. If you have any code that uses SEEK, you need to change it to a FINDFIRST method.

2) I can't think of the other ones right now, as SEEK was the only one I ever ran up against..



Jim How many of you believe in telekinesis? Raise my hand...
Another free Access forum:

http://www.forumco.com/jmhare

More Access stuff at

http://www.jmhare.com/wildhare2.htm

 

[cainemart]

Jim,

I ran into the same problem with the seek command but I found some code that will handle this problem.


************ Code Start ***************
'This code was originally written by Michel Walsh. 'It is not to be altered or distributed, 'except as part of an application. 'You are free to use it in any application, 'provided the copyright notice is left unchanged. ' 'Code Courtesy of 'Michel Walsh

Public Function OpenForSeek(TableName As String) As Recordset
‘ Assume MS-ACCESS table
Set OpenForSeek = DBEngine.Workspaces(0).OpenDatabase _ (Mid(CurrentDb().TableDefs(TableName).Connect, _ 11), False, False, "&quot.OpenRecordset(TableName, _ dbOpenTable)
End Function
'************ Code End ***************


Dim rst as Recordset
set rst=OpenForSeek("TableName&quot