[AccessD] Access databases - migration project

...good to see you back :)

...for me its always been dirty data that drove me batty ...duplicates, 
nulls, poor relational design, etc.
...which of course depends on how well designed and coded it was to begin 
with ...but it can consume a major part of any
conversion project ...and limit just how much the developer can do until the 
data quality problems are resolved.

...the major risk I see going forward is not preparing for the move to a 64 
bit world ...and not being ready for the move to the cloud ...both of which 
current versions of Access have major limitations in ...consider the move to 
64 bit akin to that from 16 bit to 32 bit with even more problems ...there 
is no backward/forward compatibility between many existing Access 32 bit 
controls and the 64 bit version of Office 2010 ...the MSCOMCTL.ocx being a 
prime example ...and no sign from MS that they will produce such ...this 
implies significant code changes in conversion projects from 32 bit Office 
to 64 bit Office ...you can live in the 32 bit WoW environment only so long 
before the need to migrate to 64 bit will become imperative.

William

--------------------------------------------------
From: <roz.clarke at barclays.com>
Sent: Wednesday, April 14, 2010 5:49 AM
To: <accessd at databaseadvisors.com>
Subject: [AccessD] Access databases - migration project

> Hi all,
>
> It's good to be back. :)
>
> I'm wondering if anyone has any general advice regarding carrying out
> current state assessments on clusters of Access databases? I can't talk
> about the purpose of the CSA (I'm under a non-disclosure agreement) but
> if you imagine all the possible reasons for doing one, I probably need
> to cover the lot.
>
> I think they are particularly interested in risks (doing nothing vs.
> doing 'something'). I have Susan and Martin's book on Access -> SQL
> Server so I can dig into the specifics there, but SQL Server is only one
> of an unknown number of options on the table. Also the databases are
> used more for extraction from other systems & subsequent analysis than
> for data storage.
>
> Any tips on what I should be looking for? Data integrity, well-formed
> data, documentation, state of the code... What else? If anyone who has
> done large scale migrations has any stories to share I'd be all ears.
>
> TIA
>
> Roz
>
> This e-mail and any attachments are confidential and intended solely for 
> the addressee and may also be privileged or exempt from disclosure under 
> applicable law. If you are not the addressee, or have received this e-mail 
> in error, please notify the sender immediately, delete it from your system 
> and do not copy, disclose or otherwise act upon any part of this e-mail or 
> its attachments.
>
> Internet communications are not guaranteed to be secure or virus-free.
> The Barclays Group does not accept responsibility for any loss arising 
> from unauthorised access to, or interference with, any Internet 
> communications by any third party, or from the transmission of any 
> viruses. Replies to this e-mail may be monitored by the Barclays Group for 
> operational or business reasons.
>
> Any opinion or other information in this e-mail or its attachments that 
> does not relate to the business of the Barclays Group is personal to the 
> sender and is not given or endorsed by the Barclays Group.
>
> Barclays Bank PLC.Registered in England and Wales (registered no. 
> 1026167).
> Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom.
>
> Barclays Bank PLC is authorised and regulated by the Financial Services 
> Authority.
>
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>