過去幾天我一直在研究這個問題，因為我準備使用拆分資料庫的第一個系統交付 3 個階段中的第一個。我想聽聽您的建議，因為我還沒有找到足夠的資訊來做出全面的決定。
目前我正在開發一個未拆分的資料庫。當我在現場拆分它時，我會復制這兩個部分，但是在第 2 階段我該如何處理它們呢？
我在想，在重新鏈接表（因為我已經有效地移動了后端）之后，我現在將它們作為我的開發版本，這意味著我不再使用未拆分的資料庫。這是正確的方法嗎？
在將第 2 階段上線時，我認為除了手動將表更新應用到實時后端（一旦備份）之外，我別無選擇。對于實時前端，我只是用我的開發前端替換它然后重新鏈接表還是將更改匯出到實時前端？我想我可以根據正在更改/新的物件的數量來做。那正確嗎？然后，我將復制并將它們作為第 3 階段的開發版本。
最后在開發中，我有表單和報告模板以及測驗表單、報告和查詢，這些是實時不需要的，所以我應該為每個部署洗掉它們，然后將它們全部重新添加到新的開發前端，還是只是把它們放在現場？通常我會把它們拿出來，但它們有很多，而且我不知道有什么快速的方法可以將它們重新添加，所以你會怎么做？
我的問題主要是從風險的角度提出的——哪些步驟可以最好地降低現場搞砸的風險。
更新：
對于那些正在尋找這個答案的人，除了下面的很好的回答，我發現以下內容可能也有幫助：
如何持續開發和部署 Access 2010 資料庫應用程式
uj5u.com熱心網友回復：
為了降低風險：您應該擁有您的開發版本、實時測驗版本和實時版本。您正在開發中開發客戶測驗測驗中的更改（使用測驗資料），然后您開始生活
為了從開發到測驗，我創建了一個更新/遷移腳本。在此腳本中包含需要在后端完成的所有更改。我使用腳本來創建測驗版本，通過它我可以檢查它是否正常作業。如果有我無法在腳本中反映的資料庫更改（技能不足或資料庫的限制），我會將它們添加到我的清單中。
我正在使用版本控制來查看開發程序中的更改并將模塊、查詢等匯入新版本。
通過匯入最新版本（不需要不需要的表格/報告）來更新前端。
uj5u.com熱心網友回復：
目前我正在開發一個未拆分的資料庫。W
不要，一個非常糟糕的主意。這是如何作業的？
好吧，在開始時可以肯定的是，您正在構建大量新表、更改關系并以高開發速度構建表。
因此，此時，您可以開發未拆分。
然后你會在一段時間后發現創建新表的速度（和需要），并且改變所謂的“資料庫模式”會平靜下來，變成一種沉悶的咆哮。
此時您仍在開發中 - 尚未部署。
那么，在這一點附近的某個地方？你想分裂。你真的很想這樣做。
這有很多原因，但有幾個是：
while a split vs non split is "very similar", they are not the same!
Thus, you can't and don't want to develop code that NOT really tested
as to HOW the code will run in the real world
因此，許多問題可能會在開發程序中發生變化或出現，在運行拆分時會有所不同。因此某些命令（例如 seek()）不起作用，并且可能會出現其他一些問題。您不想開發一整周，然后拆分，現在發現 20 個難以修復代碼中的錯誤。因此，通過盡快拆分開發，那么隨著您的開發，出現的任何和所有問題都會被看到，從而可以及時修復、看到和處理這些問題。更糟糕的是撰寫一堆代碼，準備部署，然后發現新的錯誤。
下一步：擁有一個拆分系統很棒，因為說客戶可能會讓你遠程進入他們的系統。您可以下載他們的資料副本，重新鏈接您的表格以從您的“測驗資料”指向真實的實時生產資料。
或者，說您在現場進行開發。您可能想要測驗一些危險的洗掉代碼或修改資料的代碼。所以，你不能冒險處理生產資料，所以現在你重新鏈接并指向你的測驗后端。因此，此設定允許您測驗代碼，但更重要的是，可以輕松地在資料庫副本上進行測驗。
它還允許您進行異地開發。你可以為他們的系統使用最新的前端，也許得到他們最新的資料檔案，也許沒有。但是您現在可以輕松簡單地更改您的應用程式運行的資料庫。
另一個大問題？假設您在現場作業，并在網路檔案夾中擁有他們的測驗資料庫。您撰寫一些代碼，測驗新報告。你發現它跑得像烏龜一樣慢。你檢查你的代碼，也許添加一些索引，然后繁榮！- 您的報告現在運行良好。
如果您測驗未拆分，則可能會出現大量性能問題，但在開發周期中不會出現。再一次，您不想開發數周或其他任何時間，拆分，現在發現一大堆表單和代碼運行速度真的很慢。
那么，這里的目標和想法是什么？
你想盡快分手嗎？
多久？
嗯，這是只有你才能知道的事情之一！！！
正如我所說，在開發開始時，當然，從不拆分開始。
一旦表格設計相當穩固，您就可以拆分。然后，您總是會發展為拆分（以及上面列出的原因串列非常短-還有更多原因）。
現在，問題當然是拆分？假設您要向表中添加新列？
Well, it is MORE work, since now ANY AND ALL changes to the data schema are done in the back end. So, you have to close down the front end (FE), open the back end, and now use the table designer to add that one column. (or maybe change or setup a new relationship between some tables. Or maybe add a new table).
This is a "bit more" work, since now you close down the BE, and open the FE, and now you MUST re-link tables. And if you added new tables to the BE, then you have to add that/those new table links.
Because this "dance" is extra work, that is why you wait as long as possible to split. As I stated, you "just know" when that time has arrived to split. (when table and schema tables changes settles down to a low rate of change). Since the rate of change is now low in regards to table changes, then it not much work nor pain to have to do the above every time you want to change the table structures.
In fact, think of any program you buy? It has a applcation part, and then a data file part. In effect, once you split, you have the same two parts, and in fact in some applications I written, they are allowed to use "different" back ends - not unlike any other applcation in which you launch the applcation, and THEN choose the datafile to work with.
So, what about developing off site? Well, that can be REALLY difficult, since you have your own copy of the FE and the BE.
If you HAVE TO make changes to the BE? I open up a work document. And if I add a new column to say tblCusotmers?
Then I enter this:
Add new column TaxRate, Currency, to table tblCustomers
So, you build up a "log" of changes. Now, when you travel to the customer site, and want to roll out and deploy the new FE? Well, you have to FIRST open up their BE, and make the above changes to their production BE database.
Now in some cases, where is was not possible for me to be on site? (in fact, I had a automatic update system to automatic roll out a new version of my software - and it would automatic down load from the internet. In this case? I had to write code in the FE on startup that would use VBA code to MAKE the changes to the data tables. This can be REALLY hard to do, but is possible. I just recommend the plane jane word document, and you keep track of your changes.
So, the above is quite much how this development process works.
Since you will have to re-link the tables? Then near everyone has googled for a VBA table re-link routines. You want that, since having such code is MUCH easier then say using the linked table manager each time. And we even often have a table in the FE that saves the BE server location, and on startup will check, and if the location of the files don't match, we launch the re-link code.
that way, you can deploy the applcation to different sites, and have it automatic re-link. Another way is to have a simple text file in the same location as the FE on each computer, and on startup read the text file with the BE location - and re-link if required.
So, the typical process to role out a new FE (which is placed on each work station - do NOT break this rule!!!).
So, I point/relink my front end to the production BE. I then compile down to a accDE, and then deploy that new compiled FE to all the work stations. In fact, I have some code in VBA at start up that compares a version number, and if the version number is lower, then the VBA code will copy down the next FE sitting in a folder.
This might not be a big deal if you have 2-4 users. But, if you have two sites, and each has 35 users, then you want to figure out a automated approach.
However, do not prolong jumping over to the split development cycle, as you really for all practical purposes MUST develop in a split environment. So, for the first part, you can develop un-split. But, once you split - that's it, and from that point on-wards, you are to develop as split. There are boatloads of benefits, but it also really quite much standard approach from a developer point of view.
So, you have to master the linked table manager rite quick, and then VERY much consider adding some re-link code, since you want with great ease to point to a different back end - including at deployment time.
so, as a general rule, you should think of your FE like a .exe program, for a new version roll out, yes, you copy (over write) their existing FE's on each work station. And as noted, in most cases, it should be a compiled accDE, and not a un-compiled accDB for the FE.
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/439027.html