|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Splitting a secure databaseworked out all the security issues and I am ready to update the live data with the secure schema. (I had to modify several forms, and queries so that I could secure the database with the user groups I created) I now have it the way I want it, but I am also planning to split the database. I would like to know which I should do first. 1. Should I go ahead and implement the security schema alone first? 2. Should I make another copy of the live data and work on splitting and testing the split, then implement it first then the security later? 3. Should I just continue with my secure database and split and test it, then implement both at the same time? I do understand that it is not always wise to implement multiple major changes at the same time, but with extensive planning and testing could this work ok? If I use the database splitting wizard, is it pretty straigtforward and fool proof or should I split the database on my own? Is there anything else to consider when splitting the database? Do the links handle everything or do I have to make any modifications to my code for it to find the tables? I.E. currently I am opening tables in code using currentdb.openrecordset... will this need to change? Hi tw,
I prefer to split the database first, and the create the security. Backup your database before splitting. You can use the internal "database splitter tool", there is no problem with that. If you have DAO or ADO code accessing table directly (Seek method, dbOpenTable, etc.), you'll have to fix it. Show quoteHide quote "tw" <tlsilv***@hotmail.com> escreveu na mensagem news:euseHK4PFHA.3336@TK2MSFTNGP10.phx.gbl... > My live database is currently not secure. I have a copy of it that I have > worked out all the security issues and I am ready to update the live data > with the secure schema. (I had to modify several forms, and queries so > that I could secure the database with the user groups I created) I now > have it the way I want it, but I am also planning to split the database. > I would like to know which I should do first. > > 1. Should I go ahead and implement the security schema alone first? > 2. Should I make another copy of the live data and work on splitting and > testing the split, then implement it first then the security later? > 3. Should I just continue with my secure database and split and test it, > then implement both at the same time? I do understand that it is not > always wise to implement multiple major changes at the same time, but with > extensive planning and testing could this work ok? If I use the database > splitting wizard, is it pretty straigtforward and fool proof or should I > split the database on my own? Is there anything else to consider when > splitting the database? Do the links handle everything or do I have to > make any modifications to my code for it to find the tables? I.E. > currently I am opening tables in code using currentdb.openrecordset... > will this need to change? > I went ahead and implemented security first, because it was ready the *they*
were waiting... So the next step for this database is to split. Is there any other code besides dbOpenTable or seek method that I need to be aware of ahead of time? Thanks Show quoteHide quote "Luiz Cláudio C. V. Rocha [MVP]" <luiz.semspam@mvps.org> wrote in message news:e$%23Vu79PFHA.3336@TK2MSFTNGP09.phx.gbl... > Hi tw, > > I prefer to split the database first, and the create the security. > > Backup your database before splitting. You can use the internal "database > splitter tool", there is no problem with that. > > If you have DAO or ADO code accessing table directly (Seek method, > dbOpenTable, etc.), you'll have to fix it. > > > -- > Luiz Cláudio C. V. Rocha > São Paulo - Brasil > http://br.thespoke.net/MyBlog/lccvr/MyBlog.aspx > > > "tw" <tlsilv***@hotmail.com> escreveu na mensagem > news:euseHK4PFHA.3336@TK2MSFTNGP10.phx.gbl... >> My live database is currently not secure. I have a copy of it that I >> have worked out all the security issues and I am ready to update the live >> data with the secure schema. (I had to modify several forms, and queries >> so that I could secure the database with the user groups I created) I >> now have it the way I want it, but I am also planning to split the >> database. I would like to know which I should do first. >> >> 1. Should I go ahead and implement the security schema alone first? >> 2. Should I make another copy of the live data and work on splitting and >> testing the split, then implement it first then the security later? >> 3. Should I just continue with my secure database and split and test it, >> then implement both at the same time? I do understand that it is not >> always wise to implement multiple major changes at the same time, but >> with extensive planning and testing could this work ok? If I use the >> database splitting wizard, is it pretty straigtforward and fool proof or >> should I split the database on my own? Is there anything else to >> consider when splitting the database? Do the links handle everything or >> do I have to make any modifications to my code for it to find the tables? >> I.E. currently I am opening tables in code using >> currentdb.openrecordset... will this need to change? >> > > tw,
All you need to know about securing and splitting.. :-) For information on splitting: http://www.granite.ab.ca/access/splitapp/overview.htm For information on Access User Level security: http://www.jmwild.com/SplitSecure.htm Based on the information on Joan Wild's website, to me it's much simpler to secure first and then split. Also, note the gotcha about using the builtin "splitter tool" wizard on secured databases. HTH, Immanuel Sibero Show quoteHide quote "tw" <tlsilv***@hotmail.com> wrote in message news:e0pi51DQFHA.128@tk2msftngp13.phx.gbl... > I went ahead and implemented security first, because it was ready the *they* > were waiting... So the next step for this database is to split. Is there > any other code besides dbOpenTable or seek method that I need to be aware of > ahead of time? > > Thanks > > "Luiz Cláudio C. V. Rocha [MVP]" <luiz.semspam@mvps.org> wrote in message > news:e$%23Vu79PFHA.3336@TK2MSFTNGP09.phx.gbl... > > Hi tw, > > > > I prefer to split the database first, and the create the security. > > > > Backup your database before splitting. You can use the internal "database > > splitter tool", there is no problem with that. > > > > If you have DAO or ADO code accessing table directly (Seek method, > > dbOpenTable, etc.), you'll have to fix it. > > > > > > -- > > Luiz Cláudio C. V. Rocha > > São Paulo - Brasil > > http://br.thespoke.net/MyBlog/lccvr/MyBlog.aspx > > > > > > "tw" <tlsilv***@hotmail.com> escreveu na mensagem > > news:euseHK4PFHA.3336@TK2MSFTNGP10.phx.gbl... > >> My live database is currently not secure. I have a copy of it that I > >> have worked out all the security issues and I am ready to update the live > >> data with the secure schema. (I had to modify several forms, and queries > >> so that I could secure the database with the user groups I created) I > >> now have it the way I want it, but I am also planning to split the > >> database. I would like to know which I should do first. > >> > >> 1. Should I go ahead and implement the security schema alone first? > >> 2. Should I make another copy of the live data and work on splitting and > >> testing the split, then implement it first then the security later? > >> 3. Should I just continue with my secure database and split and test it, > >> then implement both at the same time? I do understand that it is not > >> always wise to implement multiple major changes at the same time, but > >> with extensive planning and testing could this work ok? If I use the > >> database splitting wizard, is it pretty straigtforward and fool proof or > >> should I split the database on my own? Is there anything else to > >> consider when splitting the database? Do the links handle everything or > >> do I have to make any modifications to my code for it to find the tables? > >> I.E. currently I am opening tables in code using > >> currentdb.openrecordset... will this need to change? > >> > > > > > > Thanks, I have the database fully secure and have been doing well with that
for the past couple of weeks. I followed presisly the instructions to secure a database and the advice given from the newsgroups. I will check out the information you provided to split a secure database and post back if I have any problems. Thanks again. Show quoteHide quote "Immanuel Sibero" <goah***@getlost.com> wrote in message news:uq8LVBEQFHA.1268@TK2MSFTNGP14.phx.gbl... > > tw, > > All you need to know about securing and splitting.. :-) > > > For information on splitting: > http://www.granite.ab.ca/access/splitapp/overview.htm > > For information on Access User Level security: > http://www.jmwild.com/SplitSecure.htm > > > Based on the information on Joan Wild's website, to me it's much simpler > to > secure first and then split. > Also, note the gotcha about using the builtin "splitter tool" wizard on > secured databases. > > > HTH, > Immanuel Sibero > > > > "tw" <tlsilv***@hotmail.com> wrote in message > news:e0pi51DQFHA.128@tk2msftngp13.phx.gbl... >> I went ahead and implemented security first, because it was ready the > *they* >> were waiting... So the next step for this database is to split. Is there >> any other code besides dbOpenTable or seek method that I need to be aware > of >> ahead of time? >> >> Thanks >> >> "Luiz Cláudio C. V. Rocha [MVP]" <luiz.semspam@mvps.org> wrote in message >> news:e$%23Vu79PFHA.3336@TK2MSFTNGP09.phx.gbl... >> > Hi tw, >> > >> > I prefer to split the database first, and the create the security. >> > >> > Backup your database before splitting. You can use the internal > "database >> > splitter tool", there is no problem with that. >> > >> > If you have DAO or ADO code accessing table directly (Seek method, >> > dbOpenTable, etc.), you'll have to fix it. >> > >> > >> > -- >> > Luiz Cláudio C. V. Rocha >> > São Paulo - Brasil >> > http://br.thespoke.net/MyBlog/lccvr/MyBlog.aspx >> > >> > >> > "tw" <tlsilv***@hotmail.com> escreveu na mensagem >> > news:euseHK4PFHA.3336@TK2MSFTNGP10.phx.gbl... >> >> My live database is currently not secure. I have a copy of it that I >> >> have worked out all the security issues and I am ready to update the > live >> >> data with the secure schema. (I had to modify several forms, and > queries >> >> so that I could secure the database with the user groups I created) I >> >> now have it the way I want it, but I am also planning to split the >> >> database. I would like to know which I should do first. >> >> >> >> 1. Should I go ahead and implement the security schema alone first? >> >> 2. Should I make another copy of the live data and work on splitting > and >> >> testing the split, then implement it first then the security later? >> >> 3. Should I just continue with my secure database and split and test > it, >> >> then implement both at the same time? I do understand that it is not >> >> always wise to implement multiple major changes at the same time, but >> >> with extensive planning and testing could this work ok? If I use the >> >> database splitting wizard, is it pretty straigtforward and fool proof > or >> >> should I split the database on my own? Is there anything else to >> >> consider when splitting the database? Do the links handle everything > or >> >> do I have to make any modifications to my code for it to find the > tables? >> >> I.E. currently I am opening tables in code using >> >> currentdb.openrecordset... will this need to change? >> >> >> > >> > >> >> > > Hi tw,
"Seek" is most frequent problem with splitted DBs, but any code involving table structures and indexes must be fixed. Show quoteHide quote "tw" <tlsilv***@hotmail.com> escreveu na mensagem news:e0pi51DQFHA.128@tk2msftngp13.phx.gbl... >I went ahead and implemented security first, because it was ready the >*they* were waiting... So the next step for this database is to split. Is >there any other code besides dbOpenTable or seek method that I need to be >aware of ahead of time? > > Thanks > > "Luiz Cláudio C. V. Rocha [MVP]" <luiz.semspam@mvps.org> wrote in message > news:e$%23Vu79PFHA.3336@TK2MSFTNGP09.phx.gbl... >> Hi tw, >> >> I prefer to split the database first, and the create the security. >> >> Backup your database before splitting. You can use the internal "database >> splitter tool", there is no problem with that. >> >> If you have DAO or ADO code accessing table directly (Seek method, >> dbOpenTable, etc.), you'll have to fix it. >> >> >> -- >> Luiz Cláudio C. V. Rocha >> São Paulo - Brasil >> http://br.thespoke.net/MyBlog/lccvr/MyBlog.aspx >> >> >> "tw" <tlsilv***@hotmail.com> escreveu na mensagem >> news:euseHK4PFHA.3336@TK2MSFTNGP10.phx.gbl... >>> My live database is currently not secure. I have a copy of it that I >>> have worked out all the security issues and I am ready to update the >>> live data with the secure schema. (I had to modify several forms, and >>> queries so that I could secure the database with the user groups I >>> created) I now have it the way I want it, but I am also planning to >>> split the database. I would like to know which I should do first. >>> >>> 1. Should I go ahead and implement the security schema alone first? >>> 2. Should I make another copy of the live data and work on splitting and >>> testing the split, then implement it first then the security later? >>> 3. Should I just continue with my secure database and split and test it, >>> then implement both at the same time? I do understand that it is not >>> always wise to implement multiple major changes at the same time, but >>> with extensive planning and testing could this work ok? If I use the >>> database splitting wizard, is it pretty straigtforward and fool proof or >>> should I split the database on my own? Is there anything else to >>> consider when splitting the database? Do the links handle everything or >>> do I have to make any modifications to my code for it to find the >>> tables? I.E. currently I am opening tables in code using >>> currentdb.openrecordset... will this need to change? >>> >> >> > > |
|||||||||||||||||||||||
Other interesting topics