Multi user development

[abprules]

Can somehow tell me the best way for multi user development to occur in
MS Access? The situation is: We are creating a new database for a small
company. There are 2 of us who want to simultaneously work on
development. Does splitting the database and creating FE's work for
this scenario? And if so, would the changes that both users make be
saved into the original .mdb? Is there any good source that I can read
more about this in detail about how the FE works and saves changes?

I know that it must be possible for 2 or more people to develop in the
same DB at one time?? HELP!!

[pietlinden]

It's really not that hard. You can have as many people as you want
work on separate copies of the database. As long as they don't work on
the same object (or modify dependent objects), you're fine. Split the
FE and back end and distribute the FEs. Then import the finished
objects into one db.

[pietlinden]

It's really not that hard. You can have as many people as you want
work on separate copies of the database. As long as they don't work on
the same object (or modify dependent objects), you're fine. Split the
FE and back end and distribute the FEs. Then import the finished
objects into one db.

[Jamey Shuemaker]

I do it quite often. My associate and I work simultaneously on a code
project that we reference from all databases we develop, whether
traditional or FE/BE. In all cases, any standard module or class module
used is contained in the reference .mdb. We track changes to the
modules (class or standard) in a table in the referenced .mdb (which is
converted to an .mde, on delivery) by minor/major version number. As
Pietlin said, you can't work on the same object simultaneaously unless
you also have a method for tracking line/column number level changes to
that object, which is possible, though tiresome.

Our table utilizes fields for ObjectName, Version, General (comments),
Variables, Constants, Subroutine, Function, Property, Type,
Enumeration, and Event where we record changes to each of those
elements of the module or class. It may be referenced, as necessary,
using the CodeDB method. Of course, it also helps to have solid (that
is to say, standardized) commenting conventions for changes and
functionality within the module, but this object reference table gives
you an overview of changes made to each object of the database, by
version.

Because we set and utilize a reference .mdb/.mde, our development
seldom diverges and changes to other class objects like Forms is nearly
negligible. You could track developmental changes to Forms or Reports,
as well, but you're probably best to set up sound templates and use
standard naming conventions for these types of objects and the controls
they contain, which may be imported to new projects, as needed.

We've also created a standardized Toolbar that will AutoFormat (as well
as setting other aesthetic properties) the Forms or Reports, as needed,
to enforce standard naming conventions and Form/Report properties
depending on the template used to create them.

HTH

[Albert D. Kallal]

There are 2 of us who want to simultaneously work on

development. Does splitting the database and creating FE's work for
this scenario?

Well, the above only works if you both of your agree not to work on any
code, or forms that the other user is working on.

You then at the end of the day, simply import the forms + code changes into
one of your copies.

However, I think the above dance is REALLY REALLY difficult.

Your best would be use source code control. Visual Source Safe 6.0 does
work with ms-access 2003.

I not tired it with other versions, but really, VSS is the only way to
seriously approach this problem.

And if so, would the changes that both users make be
saved into the original .mdb?

huh?..er, no, not at all.

You should be running a split database now anyway. (how can you update your
users now?...next to impossible!!!).

So,

Info link

http://support.microsoft.com/kb/837136/en-us
Download page:
http://www.microsoft.com/downloads/d...displaylang=en
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com

[junk4jeremy]

I work on a team of four developers, with two outside consultants.
We've been using VSS for the last two years or so, and it's been
absolutely the only way to go. I don't know what VSS costs, so I don't
know if it makes financial sense for a two-person gig, especially one
that's considering not even splitting the FE and the BE. But I can't
imagine working any other way with a team of developers working on the
same application.

That said, we just upgraded to VSS 2005 and it's been a real pain. Lots
of corruption of the VSS database. We haven't lost any work done to the
Access database, but we have had to spend some time digging it out, and
have gotten many scary messages along the way. Still, though, even if
we bail on 05, we'll still use VSS.

Jeremy Wallce
Application Architect
Fund for the City of New York
Albert D. Kallal wrote:

There are 2 of us who want to simultaneously work on
development. Does splitting the database and creating FE's work for
this scenario?

Well, the above only works if you both of your agree not to work on any
code, or forms that the other user is working on.

You then at the end of the day, simply import the forms + code changes into
one of your copies.

However, I think the above dance is REALLY REALLY difficult.

Your best would be use source code control. Visual Source Safe 6.0 does
work with ms-access 2003.

I not tired it with other versions, but really, VSS is the only way to
seriously approach this problem.

And if so, would the changes that both users make be
saved into the original .mdb?

huh?..er, no, not at all.

You should be running a split database now anyway. (how can you update your
users now?...next to impossible!!!).

So,

Info link

http://support.microsoft.com/kb/837136/en-us
Download page:
http://www.microsoft.com/downloads/d...displaylang=en
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com

[junk4jeremy]

Jamey,

Wow, it sounds like your shop is using some seriously cool
roll-your-own widgets during your development. Any chance you'd be
willing to share your "standardized Toolbar that will AutoFormat (as
well as setting other aesthetic properties) the Forms or Reports"?

That's extremely interesting to me.

Thanks for even putting the idea out there for me.

Jeremy Wallace
Application Architect
Fund for the City of New York
Jamey Shuemaker wrote:

I do it quite often. My associate and I work simultaneously on a code
project that we reference from all databases we develop, whether
traditional or FE/BE. In all cases, any standard module or class module
used is contained in the reference .mdb. We track changes to the
modules (class or standard) in a table in the referenced .mdb (which is
converted to an .mde, on delivery) by minor/major version number. As
Pietlin said, you can't work on the same object simultaneaously unless
you also have a method for tracking line/column number level changes to
that object, which is possible, though tiresome.

Our table utilizes fields for ObjectName, Version, General (comments),
Variables, Constants, Subroutine, Function, Property, Type,
Enumeration, and Event where we record changes to each of those
elements of the module or class. It may be referenced, as necessary,
using the CodeDB method. Of course, it also helps to have solid (that
is to say, standardized) commenting conventions for changes and
functionality within the module, but this object reference table gives
you an overview of changes made to each object of the database, by
version.

Because we set and utilize a reference .mdb/.mde, our development
seldom diverges and changes to other class objects like Forms is nearly
negligible. You could track developmental changes to Forms or Reports,
as well, but you're probably best to set up sound templates and use
standard naming conventions for these types of objects and the controls
they contain, which may be imported to new projects, as needed.

We've also created a standardized Toolbar that will AutoFormat (as well
as setting other aesthetic properties) the Forms or Reports, as needed,
to enforce standard naming conventions and Form/Report properties
depending on the template used to create them.

HTH

[Jamey Shuemaker]

Jeremy,

What we have set up is a reference .mdb (or .mde when development is
complete) that contains several standard modules and several class
modules. The one referenced above for the AutoFormat function, is one
of a suite of functions written for use with a custom toolbar and
contained in a single module with other command bar functions. That
toolbar also contains CommandBarButtons to automatically resize
controls based on the longest value in their underlying ControlSource,
center controls horizontally/vertically within their section of a form,
distribute controls evenly in a section of a form or
between/under/above other controls, install one or more of our custom
class objects including writing the code to wrap them in a control of
whatever type is necessary on the form, and some other automation tasks
we utilize quite frequently. All that has greatly reduced the common
tasks related to aesthetics that make our forms all look the same and
function as expected. It also seriously reduces repetitive coding
tasks.

The AutoFormat mentioned is pretty simple. It loops through all the
controls on the form, detects their ControlType and renames them based
on our object naming conventions and other criteria like ControlSource.
It applies the same or similar names to their attached labels and other
child controls, as necessary. Then it loops again to rename any
controls that haven't already been named. Finally it sets StatusBarText
and ControlTipText properties as appropriate for the underlying
ControlSource ensuring that attached labels and child controls have
similar values. Where controls are unbound, they are named by object
naming convention and control index (of course this changes as controls
are moved, added, and deleted, but they, at least, remain unique).

Nothing fancy, but there's quite a bit of error handling involved to
get it to loop correctly through all controls as many (like labels)
don't have the same properties as those capable of containing bound
data.

ju*********@gmail.com wrote:

Jamey,

Wow, it sounds like your shop is using some seriously cool
roll-your-own widgets during your development. Any chance you'd be
willing to share your "standardized Toolbar that will AutoFormat (as
well as setting other aesthetic properties) the Forms or Reports"?

That's extremely interesting to me.

Thanks for even putting the idea out there for me.

Jeremy Wallace
Application Architect
Fund for the City of New York
Jamey Shuemaker wrote:

I do it quite often. My associate and I work simultaneously on a code
project that we reference from all databases we develop, whether
traditional or FE/BE. In all cases, any standard module or class module
used is contained in the reference .mdb. We track changes to the
modules (class or standard) in a table in the referenced .mdb (which is
converted to an .mde, on delivery) by minor/major version number. As
Pietlin said, you can't work on the same object simultaneaously unless
you also have a method for tracking line/column number level changes to
that object, which is possible, though tiresome.

Our table utilizes fields for ObjectName, Version, General (comments),
Variables, Constants, Subroutine, Function, Property, Type,
Enumeration, and Event where we record changes to each of those
elements of the module or class. It may be referenced, as necessary,
using the CodeDB method. Of course, it also helps to have solid (that
is to say, standardized) commenting conventions for changes and
functionality within the module, but this object reference table gives
you an overview of changes made to each object of the database, by
version.

Because we set and utilize a reference .mdb/.mde, our development
seldom diverges and changes to other class objects like Forms is nearly
negligible. You could track developmental changes to Forms or Reports,
as well, but you're probably best to set up sound templates and use
standard naming conventions for these types of objects and the controls
they contain, which may be imported to new projects, as needed.

We've also created a standardized Toolbar that will AutoFormat (as well
as setting other aesthetic properties) the Forms or Reports, as needed,
to enforce standard naming conventions and Form/Report properties
depending on the template used to create them.

HTH

[junk4jeremy]

That does indeed sound like very nice code to have around. I'm guessing
by the fact that you didn't post it that you don't want to or can't do
so. Bummer. It would be great to be able to share that with folks.

In any case, it's something to consider doing over here.

Jeremy Wallace
Application Architect
Fund for the City of New York
Jamey Shuemaker wrote:

Jeremy,

What we have set up is a reference .mdb (or .mde when development is
complete) that contains several standard modules and several class
modules. The one referenced above for the AutoFormat function, is one
of a suite of functions written for use with a custom toolbar and
contained in a single module with other command bar functions. That
toolbar also contains CommandBarButtons to automatically resize
controls based on the longest value in their underlying ControlSource,
center controls horizontally/vertically within their section of a form,
distribute controls evenly in a section of a form or
between/under/above other controls, install one or more of our custom
class objects including writing the code to wrap them in a control of
whatever type is necessary on the form, and some other automation tasks
we utilize quite frequently. All that has greatly reduced the common
tasks related to aesthetics that make our forms all look the same and
function as expected. It also seriously reduces repetitive coding
tasks.

The AutoFormat mentioned is pretty simple. It loops through all the
controls on the form, detects their ControlType and renames them based
on our object naming conventions and other criteria like ControlSource.
It applies the same or similar names to their attached labels and other
child controls, as necessary. Then it loops again to rename any
controls that haven't already been named. Finally it sets StatusBarText
and ControlTipText properties as appropriate for the underlying
ControlSource ensuring that attached labels and child controls have
similar values. Where controls are unbound, they are named by object
naming convention and control index (of course this changes as controls
are moved, added, and deleted, but they, at least, remain unique).

Nothing fancy, but there's quite a bit of error handling involved to
get it to loop correctly through all controls as many (like labels)
don't have the same properties as those capable of containing bound
data.

ju*********@gmail.com wrote:

Jamey,

Wow, it sounds like your shop is using some seriously cool
roll-your-own widgets during your development. Any chance you'd be
willing to share your "standardized Toolbar that will AutoFormat (as
well as setting other aesthetic properties) the Forms or Reports"?

That's extremely interesting to me.

Thanks for even putting the idea out there for me.

Jeremy Wallace
Application Architect
Fund for the City of New York
Jamey Shuemaker wrote:

I do it quite often. My associate and I work simultaneously on a code
project that we reference from all databases we develop, whether
traditional or FE/BE. In all cases, any standard module or class module
used is contained in the reference .mdb. We track changes to the
modules (class or standard) in a table in the referenced .mdb (which is
converted to an .mde, on delivery) by minor/major version number. As
Pietlin said, you can't work on the same object simultaneaously unless
you also have a method for tracking line/column number level changes to
that object, which is possible, though tiresome.
>
Our table utilizes fields for ObjectName, Version, General (comments),
Variables, Constants, Subroutine, Function, Property, Type,
Enumeration, and Event where we record changes to each of those
elements of the module or class. It may be referenced, as necessary,
using the CodeDB method. Of course, it also helps to have solid (that
is to say, standardized) commenting conventions for changes and
functionality within the module, but this object reference table gives
you an overview of changes made to each object of the database, by
version.
>
Because we set and utilize a reference .mdb/.mde, our development
seldom diverges and changes to other class objects like Forms is nearly
negligible. You could track developmental changes to Forms or Reports,
as well, but you're probably best to set up sound templates and use
standard naming conventions for these types of objects and the controls
they contain, which may be imported to new projects, as needed.
>
We've also created a standardized Toolbar that will AutoFormat (as well
as setting other aesthetic properties) the Forms or Reports, as needed,
to enforce standard naming conventions and Form/Report properties
depending on the template used to create them.
>
HTH

[Jamey Shuemaker]

ju*********@gmail.com wrote:

That does indeed sound like very nice code to have around. I'm guessing
by the fact that you didn't post it that you don't want to or can't do
so. Bummer. It would be great to be able to share that with folks.

I don't mind, but it's highly personalized. You will have to go back
and edit it for your particular case. The lnk, btn, and msk objects are
user-defined class objects that I use repeatedly.

DSDAutoformat is the function that is attached to the CommandBarButton,
iName sets the control naming convention prefix.

WATCH FOR WORD WRAP!

' **********************Begin
Code******************************************
Public Function DSDAutoFormat()
' Callers: CommandBars("DataSorceryDesign").Controls("DataSor cery
Auto&Format...")
' Purpose: This function may be attached to a CommandBarButton to
' format all controls on the form IAW standard naming conventions.
' Assumptions: That it is being called with a form in design view
' as the currently selected object. User or system has prepared
' the StatusBarText property of all controls, as appropriate.
' This property will be copied to the ControlTipText property
' for the control itself and any child controls or attached
' labels.
' Calls: iName
' Notes: For bound forms, the 'Description' property of each
' field in the underlying table will automatically be included
' as that field's bound control's 'StatusBarText' property.
' Where 'StatusBarText' is not populated automatically, it should
' be provided by the developer prior to running this routine.

On Error GoTo Err_DSDAutoFormat

DoCmd.Hourglass True
Dim frm As Form, ctl As Control, ctl2 As Control
Dim strX(1) As String, strTip As String, strExclude As String

If Screen.ActiveForm.CurrentView <0 Then GoTo Exit_DSDAutoFormat
' Set form reference and prep counters
Set frm = Screen.ActiveForm
i = 0
j = 0
' Initiate progress meter
Call SysCmd(acSysCmdInitMeter, "Formatting parent controls:", _
frm.Controls.Count)
' Loop through controls to set properties
For Each ctl In frm.Controls
strTip = ""
strX(1) = ""
If ctl.Controls.Count 0 And ctl.ControlType <112 _
And ctl.ControlType <123 _
And ctl.ControlType <124 Then
' Control has attached controls and is not a subform,
' tab control, or tab control page
strTip = ctl.StatusBarText
' Prepare naming convention prefix
strX(0) = iName(ctl)
' Prepare naming convention subject
If ctl.ControlSource <"" _
And Left(ctl.ControlSource, 1) = "=" Then
' Calculated control
strX(1) = "Calc" & i
ElseIf ctl.ControlSource <"" Then
' Bound control
strX(1) = Replace(ctl.ControlSource, " ", "_")
Else
' Unbound control
strX(1) = "Ubd" & i
End If
' Check current ctl.Name for conventional format
' Button and mask objects excluded
If InStr(1, Left(ctl.Name, 3), strX(0), _
vbBinaryCompare) = 0 _
And Left(ctl.Name, 3) <"btn" _
And Left(ctl.Name, 3) <"msk" Then _
ctl.Name = strX(0) & IIf(strX(1) = "", i, strX(1))
' Set ControlTipText to StatusBarText
ctl.ControlTipText = IIf(strTip = "", _
ctl.ControlTipText, strTip)
' Preserve ctl.Name in exclusion string
strExclude = strExclude & "/" & ctl.Name
On Error GoTo Err_Controls
' Loop through attached/child controls
For Each ctl2 In ctl.Controls
' Prepare naming convention prefix
strX(0) = iName(ctl2)
' Set ControlTipText to Parent.StatusBarText
ctl2.ControlTipText = IIf(strTip = "", _
ctl2.ControlTipText, strTip)
' Check current ctl2.Name for conventional format
' Button and mask objects excluded
If InStr(1, Left(ctl2.Name, 3), strX(0), _
vbBinaryCompare) = 0 _
And Left(ctl2.Name, 3) <"btn" _
And Left(ctl2.Name, 3) <"msk" Then _
ctl2.Name = strX(0) & IIf(strX(1) = "", i, _
strX(1))
' Preserve ctl2.Name in exclusion string
strExclude = strExclude & "/" & ctl2.Name
Skip_ControlsCollection:
Next ctl2
On Error GoTo Err_DSDAutoFormat
End If
Skip_Controls:
' Increment control index counter and progress meter
i = i + 1
Call SysCmd(acSysCmdUpdateMeter, i)
Next ctl
' Remove progress meter
Call SysCmd(acSysCmdRemoveMeter)
On Error GoTo Err_SingleControls
' Prep counter
i = 0
' Initiate progress meter
Call SysCmd(acSysCmdInitMeter, "Formatting controls:", _
frm.Controls.Count)
' Loop through controls
For Each ctl In frm.Controls
strTip = ""
strX(1) = ""
' Control props not already set
If InStr(1, strExclude, ctl.Name) = 0 Then
strTip = ctl.StatusBarText
' Prepare naming convention prefix
strX(0) = iName(ctl)
' Prepare naming convention subject
If ctl.ControlSource <"" _
And Left(ctl.ControlSource, 1) = "=" Then
' Calculated control
strX(1) = "Calc" & i
ElseIf ctl.ControlSource <"" Then
' Bound control
Else
' Unbound control
strX(1) = "Ubd" & i
End If
' Set ControlTipText to StatusBarText
ctl.ControlTipText = IIf(strTip = "", _
ctl.ControlTipText, strTip)
' Check current ctl2.Name for conventional format
' Button and mask objects excluded
If InStr(1, Left(ctl.Name, 3), strX(0), _
vbBinaryCompare) = 0 _
And Left(ctl.Name, 3) <"btn" _
And Left(ctl.Name, 3) <"msk" Then _
ctl.Name = strX(0) & IIf(strX(1) = "", i, strX(1))
End If
Skip_UniqueControls:
' Increment control index counter and progress meter
i = i + 1
Call SysCmd(acSysCmdUpdateMeter, i)
Next ctl

Exit_DSDAutoFormat:
' Remove progress meter and hourglass
Call SysCmd(acSysCmdRemoveMeter)
DoCmd.Hourglass False
' Free object variable memory allocation
Set frm = Nothing
Exit Function

Err_DSDAutoFormat:
' Standard error handling
Select Case Err.Number
' Object does not support this property or method.
Case 438
Resume Next
' You entered the control name '???' which is already in use.
Case 2104
ctl.Name = strX(0) & strX(1) & i
Resume Next
' You entered an expression that has an invalid reference to the
property Controls.
Case 2455
Resume Skip_Controls
' You entered an expression that requires a form to be the
' active window.
' The form did not have the focus when the command was launched
Case 2475
MsgBox "Please ensure that the desired form is " _
& "has the focus and is in design mode.", vbOKOnly, _
"DataSorcery Toolbar Error"
Response = vbIgnore
Resume Exit_DSDAutoFormat
' All other errors handled without breaking to code.
Case Else
MsgBox "DataSorcery AutoFormat code error (" & Err.Number _
& "): " & StrBR(2) & Err.Description & StrBR(2) _
& "Please advise your system administrator of " _
& "this error. Control " & i & " (" & ctl.Name _
& ") could not be formatted.", vbOKOnly, _
"DataSorcery Toolbar Error"
Response = vbAbort
Resume Exit_DSDAutoFormat
End Select

Err_Controls:
' Error handling for ctl.Controls loop
Select Case Err.Number
' Object does not support this property or method.
Case 438
Resume Next
' You entered the control name '???' which is already in use.
Case 2104
ctl2.Name = strX(0) & strX(1) & j
j = j + 1
Resume Next
' You entered an expression that has an invalid reference to the
property Controls.
Case 2455
Resume Skip_ControlsCollection
' All other errors handled without breaking to code.
Case Else
MsgBox "DataSorcery Controls code error (" & Err.Number _
& "): " & StrBR(2) & Err.Description & StrBR(2) _
& "Please advise your system administrator of " _
& "this error. Control " & i & " (" & ctl.Name _
& "." & ctl2.Name & ") could not be formatted.", _
vbOKOnly, "DataSorcery Toolbar Error"
Response = vbAbort
Resume Exit_DSDAutoFormat
End Select

Err_SingleControls:
' Error handling for individual control loop
Select Case Err.Number
' Object does not support this property or method.
Case 438
Resume Next
' You entered the control name '???' which is already in use.
Case 2104
ctl.Name = strX(0) & strX(1) & i
Resume Next
' You entered an expression that has an invalid reference to the
property Controls.
Case 2455
Resume Skip_UniqueControls
' All other errors handled without breaking to code.
Case Else
MsgBox "DataSorcery UniqueControls code error (" &
Err.Number _
& "): " & StrBR(2) & Err.Description & StrBR(2) _
& "Please advise your system administrator of " _
& "this error. Control " & i & " (" & ctl.Name _
& ") could not be formatted.", vbOKOnly, "DataSorcery
Toolbar Error"
Response = vbAbort
Resume Exit_DSDAutoFormat
End Select

End Function

Private Function iName(ctl As Control) As String
' Callers: DSDAutoFormat
' Purpose: Sets naming convention prefix for controls, by type.
' Assumptions: Assumes attached labels have less than 48
' properties in all versions, and that those that are unattached
' have 48 in all versions prior to A2k3.

Dim sngLnkProps As Single
' Detect Access version for detached label identification
sngLnkProps = IIf(Application.Version >= 11, 49, 48)
' Set prefix
Select Case ctl.ControlType
Case 100 ' Label
If ctl.Properties.Count <sngLnkProps Then
' Attached label
iName = "lbl"
ElseIf Nz(ctl.HyperlinkAddress) = "" _
And Nz(ctl.HyperlinkSubAddress) = "" Then
' Detached label not used as Hyperlink
iName = "lbl"
Else
' Detached label used as Hyperlink
iName = "lnk"
End If
Case 101 ' Rectangle
iName = "box"
Case 102 ' Line
iName = "lin"
Case 103 ' Image
iName = "img"
Case 104 ' Command button
iName = "cmd"
Case 105 ' Option button
iName = "opt"
Case 106 ' Check box
iName = "chk"
Case 107 ' Option group
iName = "ogp"
Case 109 ' Text box
iName = "txt"
Case 110 ' List box
iName = "lst"
Case 111 ' Combination box
iName = "cbo"
Case 112 ' Subform
iName = "sfm"
Case 118 ' Page break
iName = "brk"
Case 122 ' Toggle button
iName = "tog"
Case 123 ' Tab control
iName = "tab"
Case 124 ' Page on tab control
iName = "pag"
Case Else ' Any other control type
iName = "ctl"
End Select
End Function
' ************************End
Code******************************************

Have fun with that one.