Moving to client/server

Hi
I have an access mdb frontend/backend app. To use sql server as backend, is
it better to keep the mdb frontend or should I switch to adp instead?
Thanks
Regards
Hi,
That does not matter. All depends up on your requirement.
Thanks
Hari
SQL Server MVP
"John" <John@.nospam.infovis.co.uk> wrote in message
news:e0AGovclFHA.2484@.TK2MSFTNGP15.phx.gbl...
> Hi
> I have an access mdb frontend/backend app. To use sql server as backend,
> is it better to keep the mdb frontend or should I switch to adp instead?
> Thanks
> Regards
>
|||What is the criteria to choose one over the other?
Regards
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:%23$GQX$dlFHA.3316@.TK2MSFTNGP14.phx.gbl...
> Hi,
> That does not matter. All depends up on your requirement.
> Thanks
> Hari
> SQL Server MVP
> "John" <John@.nospam.infovis.co.uk> wrote in message
> news:e0AGovclFHA.2484@.TK2MSFTNGP15.phx.gbl...
>
|||Per John:
>What is the criteria to choose one over the other?
If you've got an Access UI that works, I can't think of any reason to migrate to
another platform unless performance goes down the tubes when the DB is migrated
and somehow the other platform can remedy that. OTOH, keeping the same UI and
feeding with with stored procedures would probably accomplish anything that
another tool could.
PeteCresswell
|||On Sun, 31 Jul 2005 13:23:35 -0700, "(PeteCresswell)" <x@.y.z.invalid> wrote:

>Per John:
>If you've got an Access UI that works, I can't think of any reason to migrate to
>another platform unless performance goes down the tubes when the DB is migrated
>and somehow the other platform can remedy that. OTOH, keeping the same UI and
>feeding with with stored procedures would probably accomplish anything that
>another tool could.
Even switching to stored procedures is a huge job that means re-engineering
all the editable bound forms, and it's usually not necessary.
Converting queries to views and/or stored procedured is a good idea when...
1. A particular Access query can't be convinced to optimize well using linked
tables.
2. There will be multiple front-ends and you want to move much of the business
logic to the server, so it can be managed in one place without changing
multiple applications. Note that if you have SQL Server 2000 or newer, you
can often do this with Views and Instead Of triggers rather than stored
procedures, which is a much more Access-friendly way of doing it.
|||You can keep access itself as frontend
"John" wrote:

> Hi
> I have an access mdb frontend/backend app. To use sql server as backend, is
> it better to keep the mdb frontend or should I switch to adp instead?
> Thanks
> Regards
>
>

moving table from one drive to other in sql server 2000

Hi
I wanted the know the syntax, how we can move a particular table (lets say a
database having two filegroup in c, d drive) from c: drive to d: drive
without detaching that particular database
Hello,
If you have a clustered index on that table use CREATE INDEX with
DROP_EXISTING on your clustered index specifying new filegroup. THis will
move the table, data
and clustered index to the new filegroup (Data always follws the clustered
index). Incase if you do not have one then craete it temporarly on the new
file group
and drop it after.
Syntax:-
CREATE CLUSTERED INDEX <Clust_idx_name> ON Table_name
(COlumn_name) WITH DROP_EXISTING ON "NewFileGroup"
For non clustered index you could use DROP_Existing on the Create index
statement to move it to new filegroup.
Thanks
Hari
"shiva" <shiva@.discussions.microsoft.com> wrote in message
news:3EB80D03-5B8B-4032-88B5-5789B3966A5F@.microsoft.com...
> Hi
> I wanted the know the syntax, how we can move a particular table (lets say
> a
> database having two filegroup in c, d drive) from c: drive to d: drive
> without detaching that particular database

moving table from one drive to other in sql server 2000

Hi
I wanted the know the syntax, how we can move a particular table (lets say a
database having two filegroup in c, d drive) from c: drive to d: drive
without detaching that particular databaseHello,
If you have a clustered index on that table use CREATE INDEX with
DROP_EXISTING on your clustered index specifying new filegroup. THis will
move the table, data
and clustered index to the new filegroup (Data always follws the clustered
index). Incase if you do not have one then craete it temporarly on the new
file group
and drop it after.
Syntax:-
CREATE CLUSTERED INDEX <Clust_idx_name> ON Table_name
(COlumn_name) WITH DROP_EXISTING ON "NewFileGroup"
For non clustered index you could use DROP_Existing on the Create index
statement to move it to new filegroup.
Thanks
Hari
"shiva" <shiva@.discussions.microsoft.com> wrote in message
news:3EB80D03-5B8B-4032-88B5-5789B3966A5F@.microsoft.com...
> Hi
> I wanted the know the syntax, how we can move a particular table (lets say
> a
> database having two filegroup in c, d drive) from c: drive to d: drive
> without detaching that particular database