Showing posts with label become. Show all posts
Showing posts with label become. Show all posts

Sunday, February 19, 2012

Converting To ADP, Reference Recommendations

I have been creating Access applications since version 2.0 and may soon
become involved with a project that will convert an existing database
into an ADP. I would consider myself verbose in VBA, but inexperienced
using a SQL server back end. Typically when faced with a new challenge
like this one, I will read technical articles & books plus start
experimenting with code. I am sure there are many of you out there
that understand the issues I will have to confront (it worked in
'just' Access, but now...). I would appreciate recommendations
regarding books, web page links, etc., that will be helpful in my next
project.
Access version 2000 - possibly moving to 2003 next year.
Regards,
Bob<boborta@.hotmail.com> wrote in message
news:1162223068.352845.97040@.i42g2000cwa.googlegroups.com...
> I have been creating Access applications since version 2.0 and may soon
> become involved with a project that will convert an existing database
> into an ADP. I would consider myself verbose in VBA, but inexperienced
> using a SQL server back end. Typically when faced with a new challenge
> like this one, I will read technical articles & books plus start
> experimenting with code. I am sure there are many of you out there
> that understand the issues I will have to confront (it worked in
> 'just' Access, but now...). I would appreciate recommendations
> regarding books, web page links, etc., that will be helpful in my next
> project.
> Access version 2000 - possibly moving to 2003 next year.
> Regards,
Keep in mind that you can use SQL Server as a back-end and continue to use
an access mdb as the front-end. Many developers use this model. You can
still use SQL Server functionality like views, stored procedures, etc.. I
have had difficulties with ADPs and no longer attempt to use them. I also
have questions about the future of ADPs. Others have different views. Google
groups for "access adp pros cons" and you'll see there has been a lot of
discussion on this. Perhaps it has already been decided that this project
will be ADP. If so then good luck.
If the requirement is to move the data to SQL Server but the format of the
front-end is still open I would generally recommend using mdb with linked
tables to SQL Server. A lot would depend on why you are upgrading, the
application itself, the experience of the developers, etc. This is all of
course in my opinion.|||Try the book:
Microsoft Access Developers Guide to SQL Server
by Mary Chipman and Andy Baron. They address a lot of the
issues you will face in the conversion from an Access
developers perspective.
-Sue
On 30 Oct 2006 07:44:28 -0800, "boborta@.hotmail.com"
<boborta@.hotmail.com> wrote:
>I have been creating Access applications since version 2.0 and may soon
>become involved with a project that will convert an existing database
>into an ADP. I would consider myself verbose in VBA, but inexperienced
>using a SQL server back end. Typically when faced with a new challenge
>like this one, I will read technical articles & books plus start
>experimenting with code. I am sure there are many of you out there
>that understand the issues I will have to confront (it worked in
>'just' Access, but now...). I would appreciate recommendations
>regarding books, web page links, etc., that will be helpful in my next
>project.
>Access version 2000 - possibly moving to 2003 next year.
>Regards,
>Bob

Friday, February 10, 2012

Converting Non-Unicode to Unicode

What is the best way to convert a large 24/7 database to Unicode? We have
various varchar and text fields that need to become nvarchar and ntext
respectively. I know I can alter the tables to do the varchars, but that
would have to be offline (looks like like about 2 hours per column on my
50 million record table). Text fields can't be converted with an alter so
they have to be copied to a new column. I was just wondering if anybody
has experience converting these.
Why not design another table with new datatypes and use DTS or BULK insert to import data from the old table.
Once data is propogated delete the old table and rename new to old to handle the application.
HTH
--
Satya SKJ
Visit http://www.sql-server-performance.com for tips and articles on Performance topic.
"Brad" wrote:

> What is the best way to convert a large 24/7 database to Unicode? We have
> various varchar and text fields that need to become nvarchar and ntext
> respectively. I know I can alter the tables to do the varchars, but that
> would have to be offline (looks like like about 2 hours per column on my
> 50 million record table). Text fields can't be converted with an alter so
> they have to be copied to a new column. I was just wondering if anybody
> has experience converting these.
>
|||In article <38E5F8AA-A720-4E27-A01F-9BB364263191@.microsoft.com>,
satyaskj@.yahoo.co.uk said...
> Why not design another table with new datatypes and use DTS or BULK insert to import data from the old table.
> Once data is propogated delete the old table and rename new to old to handle the application.
Because I need to do it as on-line as possible. If I do a copy I will
have to shut down the site before I begin and I know it will take quite a
while.

Converting Non-Unicode to Unicode

What is the best way to convert a large 24/7 database to Unicode? We have
various varchar and text fields that need to become nvarchar and ntext
respectively. I know I can alter the tables to do the varchars, but that
would have to be offline (looks like like about 2 hours per column on my
50 million record table). Text fields can't be converted with an alter so
they have to be copied to a new column. I was just wondering if anybody
has experience converting these.Why not design another table with new datatypes and use DTS or BULK insert t
o import data from the old table.
Once data is propogated delete the old table and rename new to old to handle
the application.
HTH
--
--
Satya SKJ
Visit http://www.sql-server-performance.com for tips and articles on Perform
ance topic.
"Brad" wrote:

> What is the best way to convert a large 24/7 database to Unicode? We have
> various varchar and text fields that need to become nvarchar and ntext
> respectively. I know I can alter the tables to do the varchars, but that
> would have to be offline (looks like like about 2 hours per column on my
> 50 million record table). Text fields can't be converted with an alter so
> they have to be copied to a new column. I was just wondering if anybody
> has experience converting these.
>|||In article <38E5F8AA-A720-4E27-A01F-9BB364263191@.microsoft.com>,
satyaskj@.yahoo.co.uk said...
> Why not design another table with new datatypes and use DTS or BULK insert
to import data from the old table.
> Once data is propogated delete the old table and rename new to old to handle the a
pplication.
Because I need to do it as on-line as possible. If I do a copy I will
have to shut down the site before I begin and I know it will take quite a
while.

Converting Non-Unicode to Unicode

What is the best way to convert a large 24/7 database to Unicode? We have
various varchar and text fields that need to become nvarchar and ntext
respectively. I know I can alter the tables to do the varchars, but that
would have to be offline (looks like like about 2 hours per column on my
50 million record table). Text fields can't be converted with an alter so
they have to be copied to a new column. I was just wondering if anybody
has experience converting these.In article <38E5F8AA-A720-4E27-A01F-9BB364263191@.microsoft.com>,
satyaskj@.yahoo.co.uk said...
> Why not design another table with new datatypes and use DTS or BULK insert to import data from the old table.
> Once data is propogated delete the old table and rename new to old to handle the application.
Because I need to do it as on-line as possible. If I do a copy I will
have to shut down the site before I begin and I know it will take quite a
while.