This is probably a dumb (or at least somewhat confusing) question ...

I thinking seriously of buying Office Pro 2007, ant he biggest reason is
that I see that Microsoft "has finally seen the light" in regards to include
the runtime distribution ... without having to buy a "Developer's Version".

The place I work at has several networked PC's and I am working on a
"Special-Orders" DB, that would require a front-end on 4 PC's and the
back-end on only one of them. Pretty typical, right?

So here's my quandry...
I have been bringing the front-end home with me almost every night, and
continue to work on additional forms, reports, code. etc.
We all know that each WinXP PC has a different path to "My Documents" to
begin with ... so you have to re-link the files no matter what you do.
Worst of all ... it's usually an "Oh Yeah" moment when it comes to the work
environment ... and these guys are skeptical enough already, without me
having to get into explanations of WHY they're seeing an error message. LOL

I have been busting my head, trying to figure out the best way of automating
this process ... putting it in the start-up form (a la Autoexec)
I messed around with several possible ".Connect" string possibilities and
Select Case statements ... UGH!!!!

So the I thought that something like the old "Application.Filesearch" method
(or a replacement) would be the best idea in an "if all else fails"
scenario.

Of course my first stop was The Access Web...
http://www.mvps.org/access/api/api0006.htm

I read there that all that is required to make this work is a reference to
Office 8.0 (MSO97.dll)
I tried it, and sure enough ... it seems to work!

So the bottom line question ... can I also include that reference in an
Access 2007 database, running on WinXP?
I'd really hate to "upgrade" ... and then find myself having to re-write a
ton of code.

"Don L" <Don.Leverton (AT) Telus (DOT) Net> wrote

Upgrading from such an old version should be OK, but keep in mind that
that's a lot of versions in the meantime that you've missed. moving from
access 97 to access 2000 was a really big leap and there's was quite a bit
of grumbling when that occurred. So you've not gone through the pain of
even going from access 97 to access 2003. Moving from access 2003 to 2007 is
a really big leap.

I'm not saying this is a problem, but you do want to keep the above in
mind. The other issue is processing. The problem is that each new version of
"any" software requires a lot more memory and a lot more processing than the
previous version. So each time you upgraded a version you tend to take a hit
in performance. since you've not dealt with those hits in performance, you
may have a lot of designs in your application that would run slow as
molasses but because you not upgraded and found out what the performance
issues are then your application may have some real performance bottlenecks
that don't run well on the newer versions of access.

Also keep in mind if you have access 2000 to 2003, then the upgrade to
a2007 is only $109 dollars. So if you have an old version of office 2000
kicking around, you can upgrade very cheaply indeed.

The only issue I would keep in mind as if your machines are up to spec.
Access came out in 1997 and that is 12 years ago. A typical pc back then had
120MHz processor and 16 megs of ram. Today a typical computer has 2300MHz
processor and 2 gigs of ram. So access 2007 requirements have grown just
like the rest of the computer industry.

Sure, you simply share a folder on that computer. All other computers will
have the SAME path name to the back end file then...right?

Right, but you just said your going to have all computers link to the SAME
back end...right?

You ARE placing the front end on EACH computer, but the path to the SAME
back
end is going to be the same because they are all linking to the one back end
on
that computer with the shared folder. So, the path name to the back end is
NOT
changing here.

Well, when you get back to work, you take your FE, link to the back end
folder on your computer (using unc path names), and then create a mde, and
then Distribute (place) that mde on each users pc. That mde will still be
pointing to the back end mdb file that is in the shared folder on your
computer.

Now, if you talking about applications that are split, but NOT multi-user
and
you need that split application to work on each machine, AND you placing
that
in my documents, then yes, you need some re-linking code. You code can
simple
assume that the back end part is in the same folder as the fe and on startup
you simply re-link based on the current dir the application is running
under.
There are number of functions in
ms-access that retunes the current directory ..so, this is just not a
problem.

Why do you need to search for a file? Either you have one shared back end on
ONE computer. The path name to that ONE back end from all other computers
will not change. NEVER use mapped drives. Simply use a unc path name

eg:

\\computerName\SharedFolder\MyData.mdb

So, as long as you link using network neighborhood , you get a unc path
name. As
long as that folder is shared, then any user on the network can open that
back end file and the path name remains un-changed.

And, if you talking about a split application on once computer in my
documents,
then just use the folding re-link code:

http://www.mvps.org/access/tables/tbl0009.htm

So, in your startup code you simply open a table in the back end...if it
don't open, then either

a) assume the back end is in the same folder if you talking about a single
user system, you then just get the current path name where you are running,
and then use the above code to re-link to the back end. There is no need for
a file search here at all....

b) popup a file browse dialog in which the user can select the back end, and
then run the above re-link code. The code to pop open a file dialog browse
is:

http://www.mvps.org/access/api/api0001.htm

Note that if you frequent develop at home and them deploy remotely (not have
physical access to the work network), then you can create a small text file
in the same dir as the front end, and read the path name to the back
end..and then re-link.

Between the above two routines...in a short bit of time you can cobble
together some re-linking code.

I would say that just about every developer is faced with your Scenario and
has written some re-link code based on the above two routines. We all had to
deal with this issue...

I speak about dealing with and working with a split databae here:

http://www.members.shaw.ca/AlbertKal...plit/index.htm

In the above I explain and mention the issue of unc path names....

So, really...your problem is not a problem at all...


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal (AT) msn (DOT) com

Don L wrote:
Personally, I'd prefer some standardization and use something like Tony
Toews AutoFE. Especially if you want to make some updates.

"David W. Fenton" <XXXusenet (AT) dfenton (DOT) com.invalid> wrote

Access 1.0 was released in the Fall of 1992.

Somewhere, I think I have a picture of a stepping-stone on the Microsoft
campus that commemorates that date... they have a walk of similar ones
commemorating different product releases.

Thanks for that lengthy and well-thought-out reply Albert.

My concern was the front end.
When I take it home, I have to re-link to my local copy of the BE.
After I have made my revisions, I then have to take this latest revision
back to work and replace the existing FE on **4** machines.
--- I was thinking that this would require refreshing the links to be BE
**4** times. ---
I've now realized (and as you pointed out) that I could simply refresh the
links on ONE of them, and then copy *that* FE to the other 3 PC's. :-)

I dunno ... I might still play around with automating the whole process ...
but I guess it's not a huge priority.
Error #3024 / 3044 are "trappable" ... so something like this:


Private Sub cmdOpenSuppliers_Click()
On Error GoTo Err_cmdOpenSuppliers_Click

Dim stDocName As String
Dim stLinkCriteria As String

stDocName = "frmSuppliers"
DoCmd.OpenForm stDocName, , , stLinkCriteria

Exit_cmdOpenSuppliers_Click:
Exit Sub

Err_cmdOpenSuppliers_Click:
'Debug.Print Err.Number

If Err.Number = 3044 Or Err.Number = 3024 Then 'The ".Connect" string
for the tables isn't valid.
Err.Clear
Dim Msg As String
Dim CR As String

Msg = ""
CR = vbCrLf

Msg = Msg & "The '.Connect' string for the tables isn't valid." & CR
& CR
Msg = Msg & "Click 'OK' to attempt to re-link the data tables to the
'Back-end' database."

MsgBox (Msg)

Dim MyDB As DAO.Database
Set MyDB = CurrentDb

Dim tdf As DAO.TableDef
Dim MyTable As String
Dim strConnect As String

Dim intTableCount
Dim intSuccess As Integer

strConnect = MyDB.TableDefs("tblSuppliers").Connect 'Pick any table
name, as all tables will have the same 'Connect' string...

Select Case strConnect

Case ";DATABASE=C:\Documents and Settings\Don\My
Documents\SpecialOrders2009_be.mdb"
strConnect =
";DATABASE=\\P4-2400\SharedDocs\SpecialOrders2009_be.mdb"


Case ";DATABASE=\\P4-2400\SharedDocs\SpecialOrders2009_be.mdb"
strConnect = ";DATABASE=C:\Documents and Settings\Don\My
Documents\SpecialOrders2009_be.mdb"

End Select

intTableCount = 0
intSuccess = 0

For Each tdf In MyDB.TableDefs
MyTable = tdf.Name

If Len(tdf.Connect) > 0 Then 'We only want to deal with LINKED
tables here!
intTableCount = intTableCount + 1
tdf.Connect = strConnect
tdf.RefreshLink

If Err.Number <> 0 Then 'RefreshLink has failed.
'Debug.Print MyTable & ", " & Err.Number
Err.Clear
GoTo GetNext
Else
intSuccess = intSuccess + 1
'Debug.Print MyTable & ", " & intSuccess
End If 'for Err.Number

End If 'for Len >0

GetNext:
Next tdf

Msg = ""
Msg = Msg & intSuccess
Msg = Msg & " of "
Msg = Msg & intTableCount & " tables" & CR & CR
Msg = Msg & "Have been sucessfully re-linked."

MsgBox (Msg)

Set MyDB = Nothing

Else 'for original If Err.Number = 3024 or 3044
MsgBox Err.Description
Resume Exit_cmdOpenSuppliers_Click
End If

End Sub
================================================== ====

I've also realized that I can get the answer to "Can I use the
'Application.FileSearch' from MSO97.DLL in Access2007" by simply trying it
here later today, as I *have* downloaded the 60-day trial version of Office
Pro 2007.


"Albert D. Kallal" <PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote

<snip>

Well, ya gotta understand David, that I do this as a "hobby", and that 10
years ago ... $300 MORE (above the cost of Office Pro) was a significant
expense.

I have always felt that Microsoftoft should have included the runtime with the
"Pro" version (as they now do).
What is the point of being able to create apps (in a small business
environment ... for your own use) without having the ability to *legally*
distribute them / install them on a small peer-to-peer network?

I have only ever sold any of my "apps" to a few customers of mine, and I
told them up front that they would have to buy a legal copy of OfficePro in
order to use it. I got a little wiser, later on, and realized that many of
them already had a "runtime version" of Access that was installed with
Simply Accounting. ;-)

As it is now ... the "support charges" that I collect from these customers
pays for my software upgrades ... so I'm happy. :-)

Don


"David W. Fenton" <XXXusenet (AT) dfenton (DOT) com.invalid> wrote

"David W. Fenton" <XXXusenet (AT) dfenton (DOT) com.invalid> wrote

Golly...is it that long ago....wow...just wow........

I mean, load up access 2.0...and it runs darn near like assembler on a new
box.

What have we done with all this processing we have to day!.....


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal (AT) msn (DOT) com

"Albert D. Kallal" <PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote

And, you will have to run it on a weenie-little machine with no more than
1GB of memory, or in a VM with no more than that, if I understand correctly.
But, if that's the case, and you don't worry about your application,
including code, but not including data, being stolen by a casual passerby,
it's a nice, solid, stable thing. I supported clients who used it, 'way,
'way beyond its "day in the sun" -- completed my last newly developed Access
2.0 application in January 2000, pro bono for someone who had Office Pro 4.3
on an old machine, and didn't want to upgrade.

(But, as I said at the time, in regards to your application itself, Access
2.0 security had a hole big enough to fly the Mir through -- <chuckle>
anyone who doesn't remember what the "Mir" was will just have to Google it.)

Wasted much of it, I fear. Wonder what a Pentium 1, 166 MHZ would sell for,
these days -- I know I ran Access 2.0 on one of those; and on an AMD 233(?)
266(?) MHZ notebook.

Larry

"Don L" <Don.Leverton (AT) Telus (DOT) Net> wrote

<snip>


And the answer is .... nope.
I tried to attach it to the list of references. It *looked like* it had
accepted it, but the code wouldn't run.
Closing and re-opening it resulted in the reference disappearing altogether.

Don