Access Version and "DoCmd.RunCommand acCmdDatabaseSplitter"

[Marcel Stoop]

Hi

I know that you can use DoCmd.RunCommand acCmdDatabaseSplitter only in
Access Version XP and Higher.

So I have created following code:

If sAccVersion => "10.0" Then
DoCmd.RunCommand acCmdDatabaseSplitter
Else
MsgBox "........"
Exit Sub
End If

Some users user Acc2000 and some XP.
The users with Acc2000 have of course problems with the lines of code above,
because Acc2000 can not read:
DoCmd.RunCommand acCmdDatabaseSplitter

So my question is:
Is it possible to use acCmdDatabaseSplitter in my code without getting
problems with the users who use Acc2000.

Thanks for the help.

Marcel

 

[Douglas J. Steele]

Why do you need to programmatically split your application? To be honest,
I've never been able to figure out why they bothered adding that command.

If you do have a legitimate reason, looking up "conditional compiling" in
the Help file.

 

[Allen Browne]

Try:

If Val(SysCmd(acSysCmdAccessVer)) > 10 Then
RunCommand 520
Else ...

The RunCommand constants are just long integers. The number 520 won't give a
compilation error (even though Access 2000 could not execute the command.)

A string comparion won't work, since "10" is less than "9"

Like Doug, I can't imagine using the splitter like that, but the above
should get you out of trouble.

 

[Marcel Stoop]

One good reason could be. You want to give the user of your Access
Application the possibility of splitting the Access DB in to a FE and BE.
But you do not want to give him the access to the database Screen. You do
not want to show him all the masks, code, and tables. OK, one could make a
..mde file, but this only partly solves the problem.

I hope this is a legitimate reason.

Cheers
Marcel

 

[Marcel Stoop]

Hi Allen

Thanks for the help. I will try it.

One good reason could be. You want to give the user of your Access
Application the possibility of splitting the Access DB in to a FE and BE.
But you do not want to give him the access to the database Screen. You do
not want to show him all the masks, code, and tables. OK, one could make a
..mde file, but this only partly solves the problem.

I hope this is a legitimate reason.

Cheers
Marcel

 

[Allen Browne]

Okay: what I normally do is split the mdb into the FE and BE before giving
it to the user.

You should find that code works fine. The OpenRelReport() procedure in this
link
http://allenbrowne.com/AppRelReportCode.html
does exactly that kind of thing with
RunCommand acCmdPrintRelationships
which doesn't work in earlier versions of Access.

 

[Marcel Stoop]

I know, that that could be a possible solution, but my goal is to create
only one file to be deliverd to the users, and I want my application to be
as flexible as possible. So for me this is the only workable solution.

Thanks again, you really helped me.

Cheers
Marcel

 

[Douglas J. Steele]

You can create the backend in code, using DAO, ADOX or running DDL.

Unfortunately, it's too detailed to give an example here in the newsgroups:
I wrote a 4 part article for Access Advisor magazine about how to do this.