迁移远离MS-Access [英] Migrating away from MS-Access
问题描述
你好，我诅咒我的工作地点......我花了一个月的时间来实现它...
情景：
我刚刚进入角色，将访问数据库迁移到VB.Net。
访问数据库在终端服务上运行，并支持大约25-30
用户。它耗尽大量时间，数据损坏，前端变化
对于不熟悉系统的人很难（我），表格
结构不好.. 。非常糟糕....后端附有一个网站
以及...
在某个阶段，我们必须将访问后端迁移到SQL Server。
问题是它全部正在使用中，我们无法停机。
什么方法最好？我怎么能修复这个狡猾的设计呢？
我可以用它来运行并在狡猾的情况下建立狡猾... fark ...哈哈
上帝的帮助如果我这样做的下一个人...
我可以说服管理层聘请其他人在两个系统上并行开发，这样后端是固定的吗？
我可以根据想法改进开发新的VB.net前端，然后在我们迁移时修复
数据库结构
我可以迁移访问后端到sqlServer后端并继续使用
Access前端，我非常怀疑前端会掉进一大堆垃圾......
我想我不是在寻找答案，只是发泄和好奇地看到
其他人有什么东西...
感谢阅读！
John
Hello there, Im cursing my place of employment...and its taken me a month to
realise it...
The scenario:
Ive just stepped into a role to migrate an access database to VB.Net. The
access database runs on terminal services and supports approximatly 25-30
users. It is crapping out big time, corrupted data, changes to the front end
are difficult for someone unfamiliar with the system (me), the table
structure is bad...really bad....there is a website attached to the backend
aswell...
At some stage we have to migrate the access backend to SQL Server. The
problem is that its all in use and we cannot have downtime.
What approach is best? How can I even fix this dodgy design?
I could just run with it and build dodgyness over dodgyness...fark...haha
god help the next guy if i did that...
I could convince management to hire someone else to develop in parrallel on
both systems so the backend is fixed?
I could develop the new VB.net front end with changes in mind, then fix the
database structure when we migrate
I could migrated access backend to sqlServer backend and continue to use the
Access front end, I very much suspect the front end will fall into a big
pile of crap...
I guess Im not really looking for answers, just venting and curious to see
what other people have delt with...
Thanks for reading!
John
推荐答案
John写道：
John wrote:
你好，我诅咒我的工作地点。 ..它花了我一个月的时间来实现它......
场景：
我刚刚进入了将访问数据库迁移到VB.Net的角色。
访问数据库在终端服务上运行并支持
大约25-30个用户。它耗尽了大量时间，损坏了b $ b数据，前端的变化对于不熟悉的人来说很困难
与系统（我），表结构很差.. .really
糟糕......后端附有一个网站...
在某个阶段我们必须将访问后端迁移到SQL Server。
问题是它全部正在使用中，我们无法停机。
什么方法最好？我怎么能修复这个狡猾的设计呢？
我可以用它来运行并建立狡猾的结果
狡猾... fark ...哈哈上帝的帮助如果我这样做的下一个人...
我可以说服管理层聘请其他人在两个系统上并行开发
，这样后端是固定的吗？
我可以开发新的VB.net前端并记住更改，然后
在我们迁移时修复数据库结构
我可以迁移访问后端到sqlServer后端并继续使用Access前端的
，我非常怀疑前端会掉进一大堆废话......
我想我不是真的在寻找答案，只是发泄和好奇
看看其他人有什么东西...
感谢您的阅读！
John
Hello there, Im cursing my place of employment...and its taken me a
month to realise it...
The scenario:
Ive just stepped into a role to migrate an access database to VB.Net.
The access database runs on terminal services and supports
approximatly 25-30 users. It is crapping out big time, corrupted
data, changes to the front end are difficult for someone unfamiliar
with the system (me), the table structure is bad...really
bad....there is a website attached to the backend aswell...
At some stage we have to migrate the access backend to SQL Server. The
problem is that its all in use and we cannot have downtime.
What approach is best? How can I even fix this dodgy design?
I could just run with it and build dodgyness over
dodgyness...fark...haha god help the next guy if i did that...
I could convince management to hire someone else to develop in
parrallel on both systems so the backend is fixed?
I could develop the new VB.net front end with changes in mind, then
fix the database structure when we migrate
I could migrated access backend to sqlServer backend and continue to
use the Access front end, I very much suspect the front end will fall
into a big pile of crap...
I guess Im not really looking for answers, just venting and curious
to see what other people have delt with...
Thanks for reading!
John
带有MDB文件后端的dot-net前端是世界上最差的。
开发新的dot-net前端（如果你是的话）坚持那个有问题的决定）和SQL Server后端分开，直到它们经过足够的测试，以便将所有数据迁移到b $ b。如果现有的表格结构设计不佳，尤其如此。
在SQL的后端构建相同的糟糕设计存在零点
服务器甚至更少一点建立一个新的前端，它将花费尽可能多的时间和资源作为dot-net只会将它连接到一个表结构<已知
是有缺陷的。
我认为在SQL Server上创建一个改进的后端然后使用
修改您的Access前端版本可能是最简单且最快速的解决方案，也是您对结果最满意的解决方案。你
当然可以分阶段做到这一点。没有理由认为所有
表需要一次迁移到SQL Server。与
相关的桌子组应该保持在一起，但是个别团体和一些支持
桌子可以单独移动。
-
Rick Brandt，Microsoft Access MVP
电子邮件（视情况而定）至...
在Hunter dot com的RBrandt
A dot-net front end with an MDB file back end is the worst of all worlds.
Develop both the new dot-net front end (if you are stuck with that questionable
decision) and SQL Server back end separately until they are tested enough to
migrate all of the data over. That is especially true if the existing table
structures are poorly designed.
There is ZERO point in building the same bad designs in your back end on a SQL
Server and even less point in building a new front end that will take as much
time and resources as dot-net will only to connect it to a table structure that
is known to be deficient.
In my opinion creating an improved back end on the SQL Server and then using a
modified version of your Access front end is likely to be the simplest and
fastest solution and one where you will be most satisfied with the result. You
can of course do this in stages. There is no reason to feel that ALL of the
tables need to be migrated at one time to SQL Server. Groups of tables that are
related should be kept together, but individual groups and some supporting
tables can be moved separately.
--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
就我所见（如果你遇到的问题比我有的话）：主要
问题潜水DEEP到.net和SQL服务器（即你的知识）
所以最好的解决方案就是和好的一起做这个项目
导师。你发展了，但你的梅托可以帮助你避免最大的陷阱。
我个人的青睐是和LINQ一起打赌VS 2008和
Silverlight 1.1 ...
我认为这主要是说服合适的人，他们投入教育/指导的钱是值得的。 ..
mfg
克劳斯
Hi,
as far as i see it (if you''ve similar problems than I have): the main
problem ist diving DEEP into .net and SQL server (ie your knowledge)
So the best solution would be to do that project together with a good
"mentor". You develop, but your metor helps you to avoid the biggest traps.
My personal favour would be to bet on VS 2008 together with LINQ and
Silverlight 1.1 ...
I think it''s mainly a question of convincing the right people that the money
they put into education/mentoring is worth while ...
mfg
Klaus
在Sun， 2007年10月14日22:39:38 +1000，约翰 < no **** @ nospam.comwrote：
面对这些问题，我首先会在这些领域的现有应用程序上添加创可贴最常用的。然后我会重新设计数据库并使用新的UI和数据转换程序
将尽可能多的数据从旧数据库复制到新数据库。
如果您不熟悉用户需求，您需要花费大量时间来分析这些需求，并从
$ b $获得支持。 b新设计的管理。
-Tom。
On Sun, 14 Oct 2007 22:39:38 +1000, "John" <no****@nospam.comwrote:
Confronted with these problems I would first put band-aids on the
existing app in those areas that are used the most. Then I would
redesign the db and work on the new UI and a data conversion program
that copies as much as possible data from old to new db.
If you are unfamiliar with the users needs, you''ll need to spend a
fair amount of time analyzing those needs, and getting buy-in from
management for the new design.
-Tom.
>你好，我诅咒我的就业地点...它花了我一个月的时间来实现它......
情景：我刚刚进入角色，将访问数据库迁移到VB 。净。
访问数据库在终端服务上运行，并且支持大约25-30个用户。它正在耗费大量时间，数据损坏，前端变化对于不熟悉系统的人来说很难（我），表结构很差......真的很糟糕......那里是一个附加到后端的网站
在某个阶段，我们必须将访问后端迁移到SQL Server。
问题是它全部在使用中，我们不能停机。
最好的方法是什么？我怎么能修复这个狡猾的设计呢？
我可以用它来运行并在狡猾的情况下建立狡猾... fark ...哈哈
如果我这样做，上帝帮助下一个人。 ..
我可以说服管理层聘请其他人在两个系统上并行开发，以便后端得到修复吗？
我可以开发新的VB.net前端，并改变主意，然后在我们迁移时修复
数据库结构
我可以将访问后端迁移到sqlServer后端并继续使用
Access前端，我非常怀疑前端会变成一个大的<一堆废话...
我想我不是在寻找答案，只是发泄并好奇地看到其他人已经接受了什么...
谢谢阅读！
约翰
>Hello there, Im cursing my place of employment...and its taken me a month to
realise it...
The scenario:
Ive just stepped into a role to migrate an access database to VB.Net. The
access database runs on terminal services and supports approximatly 25-30
users. It is crapping out big time, corrupted data, changes to the front end
are difficult for someone unfamiliar with the system (me), the table
structure is bad...really bad....there is a website attached to the backend
aswell...
At some stage we have to migrate the access backend to SQL Server. The
problem is that its all in use and we cannot have downtime.
What approach is best? How can I even fix this dodgy design?
I could just run with it and build dodgyness over dodgyness...fark...haha
god help the next guy if i did that...
I could convince management to hire someone else to develop in parrallel on
both systems so the backend is fixed?
I could develop the new VB.net front end with changes in mind, then fix the
database structure when we migrate
I could migrated access backend to sqlServer backend and continue to use the
Access front end, I very much suspect the front end will fall into a big
pile of crap...
I guess Im not really looking for answers, just venting and curious to see
what other people have delt with...
Thanks for reading!
John
这篇关于迁移远离MS-Access的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
