Access and Postgresql

[jptpjs via AccessMonster.com]

I have an application I built in Access 2003. It is an electronic medical
records program split into front end (8 computers) and back end.
This runs flawlessly. Purchased a billing program that uses Postgresql.
This resides on the same computer as our Access backend.
We keep getting knocked out of the new billing program and never get knocked
out of my Access program. The billing software provider says that Access and
Postgresql running on the same machine is causing the problem.
Has anyone ever heard of this as we cannot go without the Access program.
I don't know much about Postgresql and any help will be appreciated.

Pete

--
Message posted via http://www.accessmonster.com

[paii, Ron]

Does this software provider understand that Access is Not running on a
server that is only hosting the backed file? The Access backend is only a
file share, so I don't see how it could affect Postgresql or any other SQL
server, unless you are overloading the server.

Access runtime application exist on quite a few system. MS Office will
install it for certain features. If the provider cannot give you a better
explanation, you may need to reconsider you billing software.

"jptpjs via AccessMonster.c om" <u14870@uwewrot e in message
news:709b5f7dfb 67e@uwe...

I have an application I built in Access 2003. It is an electronic medical
records program split into front end (8 computers) and back end.
This runs flawlessly. Purchased a billing program that uses Postgresql.
This resides on the same computer as our Access backend.
We keep getting knocked out of the new billing program and never get

knocked

out of my Access program. The billing software provider says that Access

and

Postgresql running on the same machine is causing the problem.
Has anyone ever heard of this as we cannot go without the Access program.
I don't know much about Postgresql and any help will be appreciated.

Pete

--
Message posted via http://www.accessmonster.com

[Larry Linson]

"jptpjs via AccessMonster.c om" <u14870@uwewrot e

I have an application I built in Access 2003. It is an
electronic medical records program split into front end
(8 computers) and back end. This runs flawlessly.
Purchased a billing program that uses Postgresql.
This resides on the same computer as our Access
backend. We keep getting knocked out of the new
billing program and never get knocked out of my
Access program. The billing software provider says
that Access and Postgresql running on the same machine
is causing the problem.
Has anyone ever heard of this as we cannot go without
the Access program.
I don't know much about Postgresql and any help
will be appreciated.

If you have a split Access database with back-end (tables, data, and
relationships) on the server, and the front-end (queries, forms, reports,
macros, and modules) running on the user's machines, as you should, and as
it appears you do, then I know something about your billing software
provider: they know so little about Access that they have made fools of
themselves in public by blaming it for something it _could not_ be doing.

Access is NOT running on the same machine, because Jet is a file-server
database, and only accesses the back-end in the same way it would access a
file on the local machine. In the Access/Jet split database configuration,
Access does all its execution on the user's local machine. (And, in fact,
that would be the case, even if the front end were not split, or if both the
front end and back end were saved on the server, UNLESS you were
deliberately executing on the server by using Windows Terminal Services or
Citrix MetaFrame. And, even so, there would be no "interferen ce" with
PostgreSQL.)

PostgreSQL, on the other hand, is a server database and it executes on the
server, though it may be accessed via a front end that runs on the user's
machine. But, even if that front-end were created in Access, the two
applications would not interfere with one another.

So, the fact is they are _hoping_ that it is some other software interfering
so they won't have to investigate, debug, and correct their software. Now,
it IS possible that some other software could be interfering (though not
very likely), but, if so, it is not Access nor Jet.

You might suggest they can avoid making fools of themselves in public again
in the future if they learn something about other databases before trying to
blame those other databases.

Larry Linson
Microsoft Access MVP

[jptpjs via AccessMonster.com]

Thanks Larry,
Some added information is that Access is running the front end and the back
end on the same machine that is hosting the Postgresql program.
One other computer is running the same billing program with the data on the
same machine mentioned above.
Vendor says we should try only running the billing software without or the
Access emr for a while to see if it does not knock users out.
Problem is getting knocked out occurs without any warning so who knows how
long we would have to check.
Just to let you know the EMR never, ever has issues.

Pete

Larry Linson wrote:

I have an application I built in Access 2003. It is an
electronic medical records program split into front end

[quoted text clipped - 10 lines]

I don't know much about Postgresql and any help
will be appreciated.

If you have a split Access database with back-end (tables, data, and
relationship s) on the server, and the front-end (queries, forms, reports,
macros, and modules) running on the user's machines, as you should, and as
it appears you do, then I know something about your billing software
provider: they know so little about Access that they have made fools of
themselves in public by blaming it for something it _could not_ be doing.

Access is NOT running on the same machine, because Jet is a file-server
database, and only accesses the back-end in the same way it would access a
file on the local machine. In the Access/Jet split database configuration,
Access does all its execution on the user's local machine. (And, in fact,
that would be the case, even if the front end were not split, or if both the
front end and back end were saved on the server, UNLESS you were
deliberately executing on the server by using Windows Terminal Services or
Citrix MetaFrame. And, even so, there would be no "interferen ce" with
PostgreSQL.)

PostgreSQL, on the other hand, is a server database and it executes on the
server, though it may be accessed via a front end that runs on the user's
machine. But, even if that front-end were created in Access, the two
applications would not interfere with one another.

So, the fact is they are _hoping_ that it is some other software interfering
so they won't have to investigate, debug, and correct their software. Now,
it IS possible that some other software could be interfering (though not
very likely), but, if so, it is not Access nor Jet.

You might suggest they can avoid making fools of themselves in public again
in the future if they learn something about other databases before trying to
blame those other databases.

Larry Linson
Microsoft Access MVP

--
Message posted via http://www.accessmonster.com

[David W. Fenton]

"jptpjs via AccessMonster.c om" <u14870@uwewrot e in
news:70a88c6d75 d4c@uwe:

Some added information is that Access is running the front end and
the back end on the same machine that is hosting the Postgresql
program.

This should not have *anything* at all to do with PostgreSQL.
Nothing.

You should ask them to explain to you what the interaction is that's
causing this, as there's nothing inherent in Access/Jet that would
have any interaction whatsoever with PostgreSQL.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Larry Linson]

"jptpjs via AccessMonster.c om" <u14870@uwewrot e

Some added information is that Access is running
the front end and the back end on the same machine
that is hosting the Postgresql program.

Do you mean that the Access front-end and back-end reside on a disk on the
same machine as the PostgreSQL billing software? You said "8 users", so do
all those users log in, serially, to that one machine, or do they access it
from their own computers? If they access the Access front-end and back-end
from their own computers, their own computer is where _Access_ is running,
even if the front-end and back-end databases are stored on a disk on the
server. That is the way it works!

One other computer is running the same billing
program with the data on the same machine
mentioned above.
Vendor says we should try only running the billing
software without or the Access emr for a while to
see if it does not knock users out.

As David suggests, insist they explain to you, clearly, simply, and
succinctly, what interaction between Access and PostgreSQL is, in their
opinion, causing the interference. Then post back here, and I strongly
suspect we will be able to debunk that argument.

Problem is getting knocked out occurs without any
warning so who knows how long we would have to
check.

However long it takes for that to happen is how long their glib tongues
would have delayed their having to actually debug their software.

Just to let you know the EMR never, ever has issues.

But, because of (other potential) issues (which would affect the Access DB,
not some other program), it would be a good idea to put a copy of the Access
FE on each of the 8 users' own computers. You do realize that now, you are
bringing every Access object it uses across the network... much slower than
retrieving the queries, forms, reports, macros, and modules from the local
hard drive.

Larry Linson
Microsoft Access MVP

[jptpjs via AccessMonster.com]

Access Front Ends are on all the other computers.
I just wanted to make it clear that the machine that has the postgresql data
also has its own front end and the back end.
So access is running on the same machine as the postgresql.
Seems like the option they are suggesting is to not use the access program
from that computer.

Larry Linson wrote:

Some added information is that Access is running
the front end and the back end on the same machine
that is hosting the Postgresql program.

Do you mean that the Access front-end and back-end reside on a disk on the
same machine as the PostgreSQL billing software? You said "8 users", so do
all those users log in, serially, to that one machine, or do they access it
from their own computers? If they access the Access front-end and back-end
from their own computers, their own computer is where _Access_ is running,
even if the front-end and back-end databases are stored on a disk on the
server. That is the way it works!

One other computer is running the same billing
program with the data on the same machine
mentioned above.
Vendor says we should try only running the billing
software without or the Access emr for a while to
see if it does not knock users out.

As David suggests, insist they explain to you, clearly, simply, and
succinctly, what interaction between Access and PostgreSQL is, in their
opinion, causing the interference. Then post back here, and I strongly
suspect we will be able to debunk that argument.

Problem is getting knocked out occurs without any
warning so who knows how long we would have to
check.

However long it takes for that to happen is how long their glib tongues
would have delayed their having to actually debug their software.

Just to let you know the EMR never, ever has issues.

But, because of (other potential) issues (which would affect the Access DB,
not some other program), it would be a good idea to put a copy of the Access
FE on each of the 8 users' own computers. You do realize that now, you are
bringing every Access object it uses across the network... much slower than
retrieving the queries, forms, reports, macros, and modules from the local
hard drive.

Larry Linson
Microsoft Access MVP

--
Message posted via AccessMonster.c om
http://www.accessmonster.com/Uwe/For...ccess/200704/1

[David W. Fenton]

"jptpjs via AccessMonster.c om" <u14870@uwewrot e in
news:70b411bf0e 42a@uwe:

Access Front Ends are on all the other computers.
I just wanted to make it clear that the machine that has the
postgresql data also has its own front end and the back end.
So access is running on the same machine as the postgresql.
Seems like the option they are suggesting is to not use the access
program from that computer.

In other words, you're running a peer-to-peer network, with one of
the workstations hosting the PostgreSQL database as well as
functioning as a workstation running the Access app.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[jptpjs via AccessMonster.com]

That is correct.

David W. Fenton wrote:

>Access Front Ends are on all the other computers.
I just wanted to make it clear that the machine that has the
postgresql data also has its own front end and the back end.
So access is running on the same machine as the postgresql.
Seems like the option they are suggesting is to not use the access
program from that computer.

In other words, you're running a peer-to-peer network, with one of
the workstations hosting the PostgreSQL database as well as
functioning as a workstation running the Access app.

--
Message posted via AccessMonster.c om
http://www.accessmonster.com/Uwe/For...ccess/200704/1

[Larry Linson]

"jptpjs via AccessMonster.c om" <u14870@uwewrot e

I just wanted to make it clear that the machine
that has the postgresql data also has its own
front end and the back end. So access is running
on the same machine as the postgresql.

The only thing that I can think of that might cause "interferen ce" is the
limit on the number of concurrent connections in a peer-to-peer network
(varies with the OS, but not the "virtually unlimited" number supported by a
server OS).

Seems like the option they are suggesting is to
not use the access program
from that computer.

To allow work to continue in your environment, and still "give their
suggestion a try", perhaps you could move the Jet back-end to a different
machine in the peer-to-peer network, and maybe even not use the FE that's on
the same machine as the PostgreSQL server.

I don't think the latter will make any difference, but the former might
eliminate any problem with the number of connections.

Larry Linson
Microsoft Access MVP