"scubadiver" <scubadi***@discussions.microsoft.com> wrote in message
news:1198FE9B-7B7F-4502-9A2E-F160745DD6CC@microsoft.com...
> Security concerns are not my forte.
>
> When I split the database can I decide what goes in the front end and what
> goes in the back end or does Access do it for me?
>
> Is the best way to protect the back-end file simply a start up screen with
> a
> password login and password button to enable and disable the shift key?
>
> thanks
>
>

"Graham Mandeno" wrote:

> Ultimately you can make the decision about what goes in the front-end and
> what goes in the back-end, but the rules are simple:
>
> 1. All tables (with a few possible exceptions) go in the back-end and
> everything else goes in the front-end.
>
> 2. The exceptions are tables which contain data that drives the application,
> rather than data which is managed by the application.  These might be a
> table of menu/switchboard items, or a table of names and descriptions of
> monthly reports.
>
> The method you describe will not protect the back-end data.  Unless you
> properly implement user-level security on the back-end, anyone can create an
> empty database and link your back-end tables to it, thus gaining
> unrestricted access to the data.
> --
> Good Luck!
>
> Graham Mandeno [Access MVP]
> Auckland, New Zealand
>
> "scubadiver" <scubadi***@discussions.microsoft.com> wrote in message
> news:1198FE9B-7B7F-4502-9A2E-F160745DD6CC@microsoft.com...
> > Security concerns are not my forte.
> >
> > When I split the database can I decide what goes in the front end and what
> > goes in the back end or does Access do it for me?
> >
> > Is the best way to protect the back-end file simply a start up screen with
> > a
> > password login and password button to enable and disable the shift key?
> >
> > thanks
> >
> >
>
>
>

"scubadiver" <scubadi***@discussions.microsoft.com> wrote in message
news:21B8D75E-C281-43C3-A899-E33DDA3A5FFD@microsoft.com...
> Hello Graham,
>
> I have copied and split the database. I managed to open the back end using
> the "exclusive option" and set a password. I created a blank database and
> tried to import the tables from the back and the password box comes up,
> preventing any copying from the back end.
>
> Is this good enough?
>
> Something I want to check is that the front end file can be put on local
> computer drives and there will be no problem with multi-users entering
> records.
>
> cheers!
>
> "Graham Mandeno" wrote:
>
>> Ultimately you can make the decision about what goes in the front-end and
>> what goes in the back-end, but the rules are simple:
>>
>> 1. All tables (with a few possible exceptions) go in the back-end and
>> everything else goes in the front-end.
>>
>> 2. The exceptions are tables which contain data that drives the
>> application,
>> rather than data which is managed by the application.  These might be a
>> table of menu/switchboard items, or a table of names and descriptions of
>> monthly reports.
>>
>> The method you describe will not protect the back-end data.  Unless you
>> properly implement user-level security on the back-end, anyone can create
>> an
>> empty database and link your back-end tables to it, thus gaining
>> unrestricted access to the data.
>> --
>> Good Luck!
>>
>> Graham Mandeno [Access MVP]
>> Auckland, New Zealand
>>
>> "scubadiver" <scubadi***@discussions.microsoft.com> wrote in message
>> news:1198FE9B-7B7F-4502-9A2E-F160745DD6CC@microsoft.com...
>> > Security concerns are not my forte.
>> >
>> > When I split the database can I decide what goes in the front end and
>> > what
>> > goes in the back end or does Access do it for me?
>> >
>> > Is the best way to protect the back-end file simply a start up screen
>> > with
>> > a
>> > password login and password button to enable and disable the shift key?
>> >
>> > thanks
>> >
>> >
>>
>>
>>

"Graham Mandeno" wrote:

> Hi again
>
> I did say you should "properly implement user-level security on the
> back-end".  Setting a database password is NOT user-level security.
> However, if you just want to erect a flimsy barrier to keep out the curious,
> then it will probably suffice.
>
> If you added the database password AFTER you linked the tables, then you
> will no longer be able to open them from the front-end.  You must delete the
> linked tables from the front-end (this deletes only the links, not the data)
> and then relink them.  You will be prompted for the password when relinking.
>
> Have you read the Access Security FAQ?  If not, then I *strongly* recommend
> you check it out on-line at:
>     http://support.microsoft.com/support/access/content/secfaq.asp
> or you can download a self-extracting file by visiting:
>     http://support.microsoft.com/?id=207793
>
> Read it, then re-read it, then go to sleep with it under your pillow :-)
> --
> Good Luck!
>
> Graham Mandeno [Access MVP]
> Auckland, New Zealand
>
> "scubadiver" <scubadi***@discussions.microsoft.com> wrote in message
> news:21B8D75E-C281-43C3-A899-E33DDA3A5FFD@microsoft.com...
> > Hello Graham,
> >
> > I have copied and split the database. I managed to open the back end using
> > the "exclusive option" and set a password. I created a blank database and
> > tried to import the tables from the back and the password box comes up,
> > preventing any copying from the back end.
> >
> > Is this good enough?
> >
> > Something I want to check is that the front end file can be put on local
> > computer drives and there will be no problem with multi-users entering
> > records.
> >
> > cheers!
> >
> > "Graham Mandeno" wrote:
> >
> >> Ultimately you can make the decision about what goes in the front-end and
> >> what goes in the back-end, but the rules are simple:
> >>
> >> 1. All tables (with a few possible exceptions) go in the back-end and
> >> everything else goes in the front-end.
> >>
> >> 2. The exceptions are tables which contain data that drives the
> >> application,
> >> rather than data which is managed by the application.  These might be a
> >> table of menu/switchboard items, or a table of names and descriptions of
> >> monthly reports.
> >>
> >> The method you describe will not protect the back-end data.  Unless you
> >> properly implement user-level security on the back-end, anyone can create
> >> an
> >> empty database and link your back-end tables to it, thus gaining
> >> unrestricted access to the data.
> >> --
> >> Good Luck!
> >>
> >> Graham Mandeno [Access MVP]
> >> Auckland, New Zealand
> >>
> >> "scubadiver" <scubadi***@discussions.microsoft.com> wrote in message
> >> news:1198FE9B-7B7F-4502-9A2E-F160745DD6CC@microsoft.com...
> >> > Security concerns are not my forte.
> >> >
> >> > When I split the database can I decide what goes in the front end and
> >> > what
> >> > goes in the back end or does Access do it for me?
> >> >
> >> > Is the best way to protect the back-end file simply a start up screen
> >> > with
> >> > a
> >> > password login and password button to enable and disable the shift key?
> >> >
> >> > thanks
> >> >
> >> >
> >>
> >>
> >>
>
>
>

"scubadiver" <scubadi***@discussions.microsoft.com> wrote in message
news:1A19F739-A462-4B8E-BCB4-4E70600A487A@microsoft.com...
> Access security is rather intimidating as I don't have an IT background.
> thanks for the links.
>
> "Graham Mandeno" wrote:
>
>> Hi again
>>
>> I did say you should "properly implement user-level security on the
>> back-end".  Setting a database password is NOT user-level security.
>> However, if you just want to erect a flimsy barrier to keep out the
>> curious,
>> then it will probably suffice.
>>
>> If you added the database password AFTER you linked the tables, then you
>> will no longer be able to open them from the front-end.  You must delete
>> the
>> linked tables from the front-end (this deletes only the links, not the
>> data)
>> and then relink them.  You will be prompted for the password when
>> relinking.
>>
>> Have you read the Access Security FAQ?  If not, then I *strongly*
>> recommend
>> you check it out on-line at:
>>     http://support.microsoft.com/support/access/content/secfaq.asp
>> or you can download a self-extracting file by visiting:
>>     http://support.microsoft.com/?id=207793
>>
>> Read it, then re-read it, then go to sleep with it under your pillow :-)
>> --
>> Good Luck!
>>
>> Graham Mandeno [Access MVP]
>> Auckland, New Zealand
>>
>> "scubadiver" <scubadi***@discussions.microsoft.com> wrote in message
>> news:21B8D75E-C281-43C3-A899-E33DDA3A5FFD@microsoft.com...
>> > Hello Graham,
>> >
>> > I have copied and split the database. I managed to open the back end
>> > using
>> > the "exclusive option" and set a password. I created a blank database
>> > and
>> > tried to import the tables from the back and the password box comes up,
>> > preventing any copying from the back end.
>> >
>> > Is this good enough?
>> >
>> > Something I want to check is that the front end file can be put on
>> > local
>> > computer drives and there will be no problem with multi-users entering
>> > records.
>> >
>> > cheers!
>> >
>> > "Graham Mandeno" wrote:
>> >
>> >> Ultimately you can make the decision about what goes in the front-end
>> >> and
>> >> what goes in the back-end, but the rules are simple:
>> >>
>> >> 1. All tables (with a few possible exceptions) go in the back-end and
>> >> everything else goes in the front-end.
>> >>
>> >> 2. The exceptions are tables which contain data that drives the
>> >> application,
>> >> rather than data which is managed by the application.  These might be
>> >> a
>> >> table of menu/switchboard items, or a table of names and descriptions
>> >> of
>> >> monthly reports.
>> >>
>> >> The method you describe will not protect the back-end data.  Unless
>> >> you
>> >> properly implement user-level security on the back-end, anyone can
>> >> create
>> >> an
>> >> empty database and link your back-end tables to it, thus gaining
>> >> unrestricted access to the data.
>> >> --
>> >> Good Luck!
>> >>
>> >> Graham Mandeno [Access MVP]
>> >> Auckland, New Zealand
>> >>
>> >> "scubadiver" <scubadi***@discussions.microsoft.com> wrote in message
>> >> news:1198FE9B-7B7F-4502-9A2E-F160745DD6CC@microsoft.com...
>> >> > Security concerns are not my forte.
>> >> >
>> >> > When I split the database can I decide what goes in the front end
>> >> > and
>> >> > what
>> >> > goes in the back end or does Access do it for me?
>> >> >
>> >> > Is the best way to protect the back-end file simply a start up
>> >> > screen
>> >> > with
>> >> > a
>> >> > password login and password button to enable and disable the shift
>> >> > key?
>> >> >
>> >> > thanks
>> >> >
>> >> >
>> >>
>> >>
>> >>
>>
>>
>>

"Graham Mandeno" wrote:

> Ultimately you can make the decision about what goes in the front-end and
> what goes in the back-end, but the rules are simple:
>
> 1. All tables (with a few possible exceptions) go in the back-end and
> everything else goes in the front-end.
>
> 2. The exceptions are tables which contain data that drives the application,
> rather than data which is managed by the application.  These might be a
> table of menu/switchboard items, or a table of names and descriptions of
> monthly reports.
>
> The method you describe will not protect the back-end data.  Unless you
> properly implement user-level security on the back-end, anyone can create an
> empty database and link your back-end tables to it, thus gaining
> unrestricted access to the data.
> --
> Good Luck!
>
> Graham Mandeno [Access MVP]
> Auckland, New Zealand
>
> "scubadiver" <scubadi***@discussions.microsoft.com> wrote in message
> news:1198FE9B-7B7F-4502-9A2E-F160745DD6CC@microsoft.com...
> > Security concerns are not my forte.
> >
> > When I split the database can I decide what goes in the front end and what
> > goes in the back end or does Access do it for me?
> >
> > Is the best way to protect the back-end file simply a start up screen with
> > a
> > password login and password button to enable and disable the shift key?
> >
> > thanks
> >
> >
>
>
>

"scubadiver" wrote:

> I have a problem with the front end file. I have tried opening the main form
> and it says "not a valid password". What is going on?
>
> "Graham Mandeno" wrote:
>
> > Ultimately you can make the decision about what goes in the front-end and
> > what goes in the back-end, but the rules are simple:
> >
> > 1. All tables (with a few possible exceptions) go in the back-end and
> > everything else goes in the front-end.
> >
> > 2. The exceptions are tables which contain data that drives the application,
> > rather than data which is managed by the application.  These might be a
> > table of menu/switchboard items, or a table of names and descriptions of
> > monthly reports.
> >
> > The method you describe will not protect the back-end data.  Unless you
> > properly implement user-level security on the back-end, anyone can create an
> > empty database and link your back-end tables to it, thus gaining
> > unrestricted access to the data.
> > --
> > Good Luck!
> >
> > Graham Mandeno [Access MVP]
> > Auckland, New Zealand
> >
> > "scubadiver" <scubadi***@discussions.microsoft.com> wrote in message
> > news:1198FE9B-7B7F-4502-9A2E-F160745DD6CC@microsoft.com...
> > > Security concerns are not my forte.
> > >
> > > When I split the database can I decide what goes in the front end and what
> > > goes in the back end or does Access do it for me?
> > >
> > > Is the best way to protect the back-end file simply a start up screen with
> > > a
> > > password login and password button to enable and disable the shift key?
> > >
> > > thanks
> > >
> > >
> >
> >
> >

"Nick" <N***@discussions.microsoft.com> wrote in message
news:FA7A163B-8931-4C63-BA53-C2219C6CD9C3@microsoft.com...
> Graham
>
> Have read your comments with interest.  Like scubadiver, the group level
> permissions scares me so I have also adopted a simple password on the
> back-end mdb file.  This works Ok except that I find that the back-end
> relationships are no longer visible in the front-end database, though stil
> enforced of course.
>
> As I use the  relationship collection to check on associated records when
> deleting items, this causes me problems.
>
> I've tried deleting and re-attaching the linked tables to no avail.
>
> Any idea what's going on?
>
> Nick
>
>
> "scubadiver" wrote:
>
>> I have a problem with the front end file. I have tried opening the main
>> form
>> and it says "not a valid password". What is going on?
>>
>> "Graham Mandeno" wrote:
>>
>> > Ultimately you can make the decision about what goes in the front-end
>> > and
>> > what goes in the back-end, but the rules are simple:
>> >
>> > 1. All tables (with a few possible exceptions) go in the back-end and
>> > everything else goes in the front-end.
>> >
>> > 2. The exceptions are tables which contain data that drives the
>> > application,
>> > rather than data which is managed by the application.  These might be a
>> > table of menu/switchboard items, or a table of names and descriptions
>> > of
>> > monthly reports.
>> >
>> > The method you describe will not protect the back-end data.  Unless you
>> > properly implement user-level security on the back-end, anyone can
>> > create an
>> > empty database and link your back-end tables to it, thus gaining
>> > unrestricted access to the data.
>> > --
>> > Good Luck!
>> >
>> > Graham Mandeno [Access MVP]
>> > Auckland, New Zealand
>> >
>> > "scubadiver" <scubadi***@discussions.microsoft.com> wrote in message
>> > news:1198FE9B-7B7F-4502-9A2E-F160745DD6CC@microsoft.com...
>> > > Security concerns are not my forte.
>> > >
>> > > When I split the database can I decide what goes in the front end and
>> > > what
>> > > goes in the back end or does Access do it for me?
>> > >
>> > > Is the best way to protect the back-end file simply a start up screen
>> > > with
>> > > a
>> > > password login and password button to enable and disable the shift
>> > > key?
>> > >
>> > > thanks
>> > >
>> > >
>> >
>> >
>> >

"Graham Mandeno" wrote:

> Hi Nick
>
> Well, blow me away! You are absolutely right!  They don't appear in the
> relationships window and they're not in the Relations collection.  I shall
> report this as a bug.
>
> As a workaround, you will need to open the backend database as a separate
> database object.  Here is a function that will return you the filename and,
> optionally, the connection string (you will need this for the password) and
> the name of the source table (in case it's different from the local name).
>
> Public Function GetBackEndName( _
>     sTable As String, _
>     Optional sConnect, _
>     Optional sForeignName _
>   ) As String
> Dim rs As DAO.Recordset
> On Error GoTo ProcErr
>   Set rs = CurrentDb.OpenRecordset( _
>     "Select Database, Connect, ForeignName from MSysObjects " _
>     & "where Type=6 and Name=""" & sTable & """", dbOpenForwardOnly)
>   If rs.RecordCount = 0 Then
>     Err.Raise vbObjectError, , "'" & sTable & "' is not a valid linked
> table"
>   Else
>     GetBackEndName = rs!Database
>     If Not IsMissing(sConnect) Then sConnect = rs!Connect
>     If Not IsMissing(sForeignName) Then sForeignName = rs!ForeignName
>   End If
> ProcEnd:
>   On Error Resume Next
>   If Not rs Is Nothing Then
>     rs.Close
>     Set rs = Nothing
>   End If
>   Exit Function
> ProcErr:
>   MsgBox Err.Description, vbExclamation
>   Resume ProcEnd
> End Function
>
> You can use it like this:
>
> Dim db As DAO.Database, rel As DAO.Relation
> Dim sBackEnd As String, sConnect As String, sSourceTable As String
>   sBackEnd = GetBackEndName("TableName", sConnect, sSourceTable)
>   Set db = OpenDatabase(sBackEnd, False, True, sConnect)
>   For Each rel In db.Relations
>     If rel.Table = sSourceTable Then
>         ... do something here
>     End If
>   Next
>
> BTW, did you know that if you link tables in a "password-protected"
> database, then anyone can read the password in plain text in your
> front-end's MSysObjects table??
>
> --
> Good Luck!
>
> Graham Mandeno [Access MVP]
> Auckland, New Zealand
>
> "Nick" <N***@discussions.microsoft.com> wrote in message
> news:FA7A163B-8931-4C63-BA53-C2219C6CD9C3@microsoft.com...
> > Graham
> >
> > Have read your comments with interest.  Like scubadiver, the group level
> > permissions scares me so I have also adopted a simple password on the
> > back-end mdb file.  This works Ok except that I find that the back-end
> > relationships are no longer visible in the front-end database, though stil
> > enforced of course.
> >
> > As I use the  relationship collection to check on associated records when
> > deleting items, this causes me problems.
> >
> > I've tried deleting and re-attaching the linked tables to no avail.
> >
> > Any idea what's going on?
> >
> > Nick
> >
> >
> > "scubadiver" wrote:
> >
> >> I have a problem with the front end file. I have tried opening the main
> >> form
> >> and it says "not a valid password". What is going on?
> >>
> >> "Graham Mandeno" wrote:
> >>
> >> > Ultimately you can make the decision about what goes in the front-end
> >> > and
> >> > what goes in the back-end, but the rules are simple:
> >> >
> >> > 1. All tables (with a few possible exceptions) go in the back-end and
> >> > everything else goes in the front-end.
> >> >
> >> > 2. The exceptions are tables which contain data that drives the
> >> > application,
> >> > rather than data which is managed by the application.  These might be a
> >> > table of menu/switchboard items, or a table of names and descriptions
> >> > of
> >> > monthly reports.
> >> >
> >> > The method you describe will not protect the back-end data.  Unless you
> >> > properly implement user-level security on the back-end, anyone can
> >> > create an
> >> > empty database and link your back-end tables to it, thus gaining
> >> > unrestricted access to the data.
> >> > --
> >> > Good Luck!
> >> >
> >> > Graham Mandeno [Access MVP]
> >> > Auckland, New Zealand
> >> >
> >> > "scubadiver" <scubadi***@discussions.microsoft.com> wrote in message
> >> > news:1198FE9B-7B7F-4502-9A2E-F160745DD6CC@microsoft.com...
> >> > > Security concerns are not my forte.
> >> > >
> >> > > When I split the database can I decide what goes in the front end and
> >> > > what
> >> > > goes in the back end or does Access do it for me?
> >> > >
> >> > > Is the best way to protect the back-end file simply a start up screen
> >> > > with
> >> > > a
> >> > > password login and password button to enable and disable the shift
> >> > > key?
> >> > >
> >> > > thanks
> >> > >
> >> > >
> >> >
> >> >
> >> >
>
>
>

"Nick" <N***@discussions.microsoft.com> wrote in message
news:FEAD4C85-13FD-4BD0-BB58-9928B52AE193@microsoft.com...
> Graham
>
> Many thanks for the prompt response and help from the other side of the
> world (i'm in England).  It's my first use of one of the forums and it was
> good to see that it wasn't just me going crazy.
>
> Not sure Microsoft will provide a fix as anything I do has to be Access97.
>
> I'd also thought of the route you've kindly suggested but was hoping I'd
> done something wrong before going that way.
>
> I'm only just getting aware of the MSysObjects table from reading the
> knowledge base but am not too sure if this storing of passwords is a
> problem.
> I suppose one option is to over-write the connection strings with false
> data
> when exiting the database and re-storing them when the user supplies the
> password on starting up.
>
> I'm really only trying to protect the data, which holds details of
> vulnerable children, against the theft of the computers, not from other
> staff
> in the various client's organisations who are all vetted.
>
>
> --
> Nick
>
>
> "Graham Mandeno" wrote:
>
>> Hi Nick
>>
>> Well, blow me away! You are absolutely right!  They don't appear in the
>> relationships window and they're not in the Relations collection.  I
>> shall
>> report this as a bug.
>>
>> As a workaround, you will need to open the backend database as a separate
>> database object.  Here is a function that will return you the filename
>> and,
>> optionally, the connection string (you will need this for the password)
>> and
>> the name of the source table (in case it's different from the local
>> name).
>>
>> Public Function GetBackEndName( _
>>     sTable As String, _
>>     Optional sConnect, _
>>     Optional sForeignName _
>>   ) As String
>> Dim rs As DAO.Recordset
>> On Error GoTo ProcErr
>>   Set rs = CurrentDb.OpenRecordset( _
>>     "Select Database, Connect, ForeignName from MSysObjects " _
>>     & "where Type=6 and Name=""" & sTable & """", dbOpenForwardOnly)
>>   If rs.RecordCount = 0 Then
>>     Err.Raise vbObjectError, , "'" & sTable & "' is not a valid linked
>> table"
>>   Else
>>     GetBackEndName = rs!Database
>>     If Not IsMissing(sConnect) Then sConnect = rs!Connect
>>     If Not IsMissing(sForeignName) Then sForeignName = rs!ForeignName
>>   End If
>> ProcEnd:
>>   On Error Resume Next
>>   If Not rs Is Nothing Then
>>     rs.Close
>>     Set rs = Nothing
>>   End If
>>   Exit Function
>> ProcErr:
>>   MsgBox Err.Description, vbExclamation
>>   Resume ProcEnd
>> End Function
>>
>> You can use it like this:
>>
>> Dim db As DAO.Database, rel As DAO.Relation
>> Dim sBackEnd As String, sConnect As String, sSourceTable As String
>>   sBackEnd = GetBackEndName("TableName", sConnect, sSourceTable)
>>   Set db = OpenDatabase(sBackEnd, False, True, sConnect)
>>   For Each rel In db.Relations
>>     If rel.Table = sSourceTable Then
>>         ... do something here
>>     End If
>>   Next
>>
>> BTW, did you know that if you link tables in a "password-protected"
>> database, then anyone can read the password in plain text in your
>> front-end's MSysObjects table??
>>
>> --
>> Good Luck!
>>
>> Graham Mandeno [Access MVP]
>> Auckland, New Zealand
>>
>> "Nick" <N***@discussions.microsoft.com> wrote in message
>> news:FA7A163B-8931-4C63-BA53-C2219C6CD9C3@microsoft.com...
>> > Graham
>> >
>> > Have read your comments with interest.  Like scubadiver, the group
>> > level
>> > permissions scares me so I have also adopted a simple password on the
>> > back-end mdb file.  This works Ok except that I find that the back-end
>> > relationships are no longer visible in the front-end database, though
>> > stil
>> > enforced of course.
>> >
>> > As I use the  relationship collection to check on associated records
>> > when
>> > deleting items, this causes me problems.
>> >
>> > I've tried deleting and re-attaching the linked tables to no avail.
>> >
>> > Any idea what's going on?
>> >
>> > Nick
>> >
>> >
>> > "scubadiver" wrote:
>> >
>> >> I have a problem with the front end file. I have tried opening the
>> >> main
>> >> form
>> >> and it says "not a valid password". What is going on?
>> >>
>> >> "Graham Mandeno" wrote:
>> >>
>> >> > Ultimately you can make the decision about what goes in the
>> >> > front-end
>> >> > and
>> >> > what goes in the back-end, but the rules are simple:
>> >> >
>> >> > 1. All tables (with a few possible exceptions) go in the back-end
>> >> > and
>> >> > everything else goes in the front-end.
>> >> >
>> >> > 2. The exceptions are tables which contain data that drives the
>> >> > application,
>> >> > rather than data which is managed by the application.  These might
>> >> > be a
>> >> > table of menu/switchboard items, or a table of names and
>> >> > descriptions
>> >> > of
>> >> > monthly reports.
>> >> >
>> >> > The method you describe will not protect the back-end data.  Unless
>> >> > you
>> >> > properly implement user-level security on the back-end, anyone can
>> >> > create an
>> >> > empty database and link your back-end tables to it, thus gaining
>> >> > unrestricted access to the data.
>> >> > --
>> >> > Good Luck!
>> >> >
>> >> > Graham Mandeno [Access MVP]
>> >> > Auckland, New Zealand
>> >> >
>> >> > "scubadiver" <scubadi***@discussions.microsoft.com> wrote in message
>> >> > news:1198FE9B-7B7F-4502-9A2E-F160745DD6CC@microsoft.com...
>> >> > > Security concerns are not my forte.
>> >> > >
>> >> > > When I split the database can I decide what goes in the front end
>> >> > > and
>> >> > > what
>> >> > > goes in the back end or does Access do it for me?
>> >> > >
>> >> > > Is the best way to protect the back-end file simply a start up
>> >> > > screen
>> >> > > with
>> >> > > a
>> >> > > password login and password button to enable and disable the shift
>> >> > > key?
>> >> > >
>> >> > > thanks
>> >> > >
>> >> > >
>> >> >
>> >> >
>> >> >
>>
>>
>>