Conversion to adp

[John]

Hi

I am converting my access front-end/backend mdb app to adp. Are there any
pitfalls I should be aware of?

Thanks

Regards

[Alan Webb]

John,
1. If the new back-end is SQL Server and the old back-end was Jet/Access
then much and perhaps all of the SQL in service may need to be revisited to
ensure it runs as intended on SQL Server. Things like DCount, etc., don't
exist on SQL Server. IIf() is implemented as CASE and works differently.
Date() is GETDATE(), "" has to be '', lots of little details are different.
2. A straight dump of Jet SQL with bug fixes & workarounds to just make the
existing SQL function on SQL Server risks really crappy performance on SQL
Server because it's possible to cause Access to do some really boneheaded
translation of SQL into something that will run on SQL Server.
3. TransactSQL is lightyears more capable than JetSQL & VBA. The
performance & stability gains possible will come from a thorough review of
the business processes implemented in Access and a study of the best way to
implement them on SQL Server.

--
Alan Webb
kn*******@SPAMh otmail.com
"It's not IT, it's IS
"John" <Jo**@nospam.in fovis.co.uk> wrote in message
news:42******** *************@n ews-text.dial.pipex .com...

Hi

I am converting my access front-end/backend mdb app to adp. Are there any
pitfalls I should be aware of?

Thanks

Regards

[Lyle Fairfield]

John wrote:

I am converting my access front-end/backend mdb app to adp. Are there any
pitfalls I should be aware of?

Only a few minor ones:

ADPs are unreliable, exhibit erratic anomalies (they happen one day but
not the next), open many connections (all of which are wonderfully
slow), have difficulty in opening a form at a specific record, have
recurring and sometimes unsolvable updating problems, require arcane
procedures for report filtering, and create a vulnerable insecure route
to the database.

Other than that they're fabulous.

Did I mention that they make your data insecure?
that's INSECURE
I-N-S-E-C-U-R-E!

--
--
Lyle

"The aim of those who try to control thought is always the same. They
find one single explanation of the world, one system of thought and
action that will (they believe) cover everything; and then they try to
impose that on all thinking people."
- Gilbert Highet

[John]

I need the sql server backend to establish replication/sync with some laptop
users who would like to disconnect and then sync when they reconnect. In my
case what is the solution? Should I keep the mdb front-end and link the
tables off sql server? Anything else?

Thanks

Regards

"Lyle Fairfield" <ly******@yahoo .ca> wrote in message
news:0P******** *************@r ead2.cgocable.n et...

John wrote:

I am converting my access front-end/backend mdb app to adp. Are there any
pitfalls I should be aware of?

Only a few minor ones:

ADPs are unreliable, exhibit erratic anomalies (they happen one day but
not the next), open many connections (all of which are wonderfully slow),
have difficulty in opening a form at a specific record, have recurring and
sometimes unsolvable updating problems, require arcane procedures for
report filtering, and create a vulnerable insecure route to the database.

Other than that they're fabulous.

Did I mention that they make your data insecure?
that's INSECURE
I-N-S-E-C-U-R-E!

--
--
Lyle

"The aim of those who try to control thought is always the same. They find
one single explanation of the world, one system of thought and action that
will (they believe) cover everything; and then they try to impose that on
all thinking people."
- Gilbert Highet

[Lyle Fairfield]

I yield to the replication experts.

John wrote:

I need the sql server backend to establish replication/sync with some laptop
users who would like to disconnect and then sync when they reconnect. In my
case what is the solution? Should I keep the mdb front-end and link the
tables off sql server? Anything else?

Thanks

Regards

"Lyle Fairfield" <ly******@yahoo .ca> wrote in message
news:0P******** *************@r ead2.cgocable.n et...

John wrote:

I am converting my access front-end/backend mdb app to adp. Are there any
pitfalls I should be aware of?

Only a few minor ones:

ADPs are unreliable, exhibit erratic anomalies (they happen one day but
not the next), open many connections (all of which are wonderfully slow),
have difficulty in opening a form at a specific record, have recurring and
sometimes unsolvable updating problems, require arcane procedures for
report filtering, and create a vulnerable insecure route to the database.

--
Lyle

"The aim of those who try to control thought is always the same. They
find one single explanation of the world, one system of thought and
action that will (they believe) cover everything; and then they try to
impose that on all thinking people."
- Gilbert Highet

[MacDermott]

There's a whole newsgroup at microsoft.publi c.access.replic ation.
It can certainly be done in Access, without requiring SQL Server.

"Lyle Fairfield" <ly******@yahoo .ca> wrote in message
news:xE******** ********@read1. cgocable.net...

I yield to the replication experts.

John wrote:

I need the sql server backend to establish replication/sync with some laptop users who would like to disconnect and then sync when they reconnect. In my case what is the solution? Should I keep the mdb front-end and link the
tables off sql server? Anything else?

Thanks

Regards

"Lyle Fairfield" <ly******@yahoo .ca> wrote in message
news:0P******** *************@r ead2.cgocable.n et...

John wrote:
I am converting my access front-end/backend mdb app to adp. Are there anypitfalls I should be aware of?

Only a few minor ones:

ADPs are unreliable, exhibit erratic anomalies (they happen one day but
not the next), open many connections (all of which are wonderfully slow),have difficulty in opening a form at a specific record, have recurring andsometimes unsolvable updating problems, require arcane procedures for
report filtering, and create a vulnerable insecure route to the

database. --
Lyle

"The aim of those who try to control thought is always the same. They
find one single explanation of the world, one system of thought and
action that will (they believe) cover everything; and then they try to
impose that on all thinking people."
- Gilbert Highet

[Steve Jorgensen]

From the quesitons you are asking, I'm assuming your situation is that you
have a central LAN with a connection to the internet, laptop users who will
have Internet access where they're trying to do their remote work, and an IT
administrator capable of managing your LAN's firewall ports, etc. If that's
the case, then your best bet is probably to use some kind of remote control
software and allow users to run their desktop systems from remote.

If remote control will not work for you, then your next best choice is
probably replication since Access may not handle the flakey SQL Server
connections you may get over the Internet, and you'll have to add a VPN layer
for security or live with the lack of security (probably not a good idea).

Note that Access replicaiton may or may not be the best way to do replication.
Sometimes, it's better to implement a replication scheme at the application
level. One way to do this is to implement a record ID generation system that
includes a machine identifier so there can't be collisions between IDs
generated on different machines, and add fields for a current and previous
record revision ID so you can tell if a record in the central database is the
same revision that a remote system made a change to while off-line, and allow
the change to post if so.

On Sun, 24 Apr 2005 15:49:14 +0100, "John" <Jo**@nospam.in fovis.co.uk> wrote:

I need the sql server backend to establish replication/sync with some laptop
users who would like to disconnect and then sync when they reconnect. In my
case what is the solution? Should I keep the mdb front-end and link the
tables off sql server? Anything else?

Thanks

Regards

"Lyle Fairfield" <ly******@yahoo .ca> wrote in message
news:0P******* **************@ read2.cgocable. net...

John wrote:

I am converting my access front-end/backend mdb app to adp. Are there any
pitfalls I should be aware of?

Only a few minor ones:

ADPs are unreliable, exhibit erratic anomalies (they happen one day but
not the next), open many connections (all of which are wonderfully slow),
have difficulty in opening a form at a specific record, have recurring and
sometimes unsolvable updating problems, require arcane procedures for
report filtering, and create a vulnerable insecure route to the database.

Other than that they're fabulous.

Did I mention that they make your data insecure?
that's INSECURE
I-N-S-E-C-U-R-E!

--
--
Lyle

"The aim of those who try to control thought is always the same. They find
one single explanation of the world, one system of thought and action that
will (they believe) cover everything; and then they try to impose that on
all thinking people."
- Gilbert Highet

[John]

Is access replication reliable enough?

Regards

"MacDermott " <ma********@nos pam.com> wrote in message
news:VF******** ***********@new sread2.news.atl .earthlink.net. ..

There's a whole newsgroup at microsoft.publi c.access.replic ation.
It can certainly be done in Access, without requiring SQL Server.

"Lyle Fairfield" <ly******@yahoo .ca> wrote in message
news:xE******** ********@read1. cgocable.net...

I yield to the replication experts.

John wrote:

> I need the sql server backend to establish replication/sync with some laptop > users who would like to disconnect and then sync when they reconnect.
> In my > case what is the solution? Should I keep the mdb front-end and link the
> tables off sql server? Anything else?
>
> Thanks
>
> Regards
>
> "Lyle Fairfield" <ly******@yahoo .ca> wrote in message
> news:0P******** *************@r ead2.cgocable.n et...
>
>>John wrote:
>>
>>
>>>I am converting my access front-end/backend mdb app to adp. Are there any >>>pitfalls I should be aware of?
>>
>>Only a few minor ones:
>>
>>ADPs are unreliable, exhibit erratic anomalies (they happen one day but
>>not the next), open many connections (all of which are wonderfully slow), >>have difficulty in opening a form at a specific record, have recurring and >>sometimes unsolvable updating problems, require arcane procedures for
>>report filtering, and create a vulnerable insecure route to the

database.

--
Lyle

"The aim of those who try to control thought is always the same. They
find one single explanation of the world, one system of thought and
action that will (they believe) cover everything; and then they try to
impose that on all thinking people."
- Gilbert Highet

[Alan Webb]

John,
It was good enough for a Y2K inventory done at a financial services company
I worked for back when I was getting paid for this stuff. As Steve points
out, there are cases where writing your own replication code ends up being
cheaper/better than what Microsoft provides in Access without code.
--
Alan Webb
kn*******@SPAMh otmail.com
"It's not IT, it's IS"

"John" <Jo**@nospam.in fovis.co.uk> wrote in message
news:42******** *************@n ews-text.dial.pipex .com...

I need the sql server backend to establish replication/sync with some
laptop users who would like to disconnect and then sync when they
reconnect. In my case what is the solution? Should I keep the mdb front-end
and link the tables off sql server? Anything else?

Thanks

Regards

"Lyle Fairfield" <ly******@yahoo .ca> wrote in message
news:0P******** *************@r ead2.cgocable.n et...

John wrote:

I am converting my access front-end/backend mdb app to adp. Are there
any pitfalls I should be aware of?

Only a few minor ones:

ADPs are unreliable, exhibit erratic anomalies (they happen one day but
not the next), open many connections (all of which are wonderfully slow),
have difficulty in opening a form at a specific record, have recurring
and sometimes unsolvable updating problems, require arcane procedures for
report filtering, and create a vulnerable insecure route to the database.

Other than that they're fabulous.

Did I mention that they make your data insecure?
that's INSECURE
I-N-S-E-C-U-R-E!

--
--
Lyle

"The aim of those who try to control thought is always the same. They
find one single explanation of the world, one system of thought and
action that will (they believe) cover everything; and then they try to
impose that on all thinking people."
- Gilbert Highet

[David W. Fenton]

Steve Jorgensen <no****@nospam. nospam> wrote in
news:10******** *************** *********@4ax.c om:

Note that Access replicaiton may or may not be the best way to do
replication. Sometimes, it's better to implement a replication
scheme at the application level. One way to do this is to
implement a record ID generation system that includes a machine
identifier so there can't be collisions between IDs generated on
different machines, and add fields for a current and previous
record revision ID so you can tell if a record in the central
database is the same revision that a remote system made a change
to while off-line, and allow the change to post if so.

This is an enormously difficult task, even if it is only one-way
between a mere two copies of the data file.

I've done it. It's complicated (think about how deletions are
propagated; think about order of inserts and referential integrity).

If you're trying to have multiple dbs in the field, all being
updated, and you want those changes pushed up to the server, and you
also want to make the changes made by people on the servers to be
pulled down to the db in the field, it becomes a hugely complicated
task, unless a few conditions are met:

1. no records are edited in more than one location.

2. each person in the field has their own dataset that they work on
alone, and no other people actually edit that data (though they may
view it and analyze it).

But even then, you have to solve the PK issue. You have three
choices:

1. use a natural key, and run the risk of the same natural key being
used in two different copies of the database.

2. pre-allocated blocks of surrogate keys to each copy of the
database.

3. include a source db identifier in a compound PK in every table.

But if everyone's working on the same datasets, it becomes nearly
impossible to program from scratch.

Keep in mind that, theoretically speaking, there is a form of
heterogenous replication where the main mother ship is a SQL Server
db and the laptops have Jet dbs that synchronize with the SQL
Server. However, like pure SQL Server replication itself, the whole
scenario is much more limited than the capabilities of pure Jet
replication, and the rules much more strict.

I don't think replication is the answer here.

I think the problem needs to be completely re-thought from the
ground up.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc