1019 - The following error occurred while attempting to determine the
Access/Jet version of the file 'X:\AutoFE\Test_Prog\\SSP_XP.ade' (while
using DAO Version 3.6)
Error: 0
---------- X:\AutoFE\Test_INIs\SSP_Test.ini--------------------
[Settings]
MainApp=%appdata%\My Database\
FileNameToStart=SSP_XP.ade
Server=X:\AutoFE\Test_Prog\
StartMethod=AutoSelect
Lockout=No
LockoutMsg=Sorry, not allowed into the system right now.
SupportMsg=Please contact your computer department for support.
ShortCutName=An excellent Access application
CreateShortCutOnDesktop=yes
CreateShortCutOnCommonDesktop=no
--------------------------------------------------------------------------------
Auto FE Updater Version: 1.76.0
Windows Version: Windows XP 5.1 build 2600 (Service Pack 3)
>I've been using the AutoFE for over two years now, and it works fine.
>However, I want to use the %appdata% variable, which is only available in
>newer versions.
>I can't seem to get the latest version to work. I keep getting the same
>error message, as below.
>I've tried just updating the sample INI that came with 1.76, and its still
>the same error.
>Can someone have a quick look at this, to see if I'm doing anything
>obviously wrong.
The problem and not very good answer is buried deep in the following
page: http://www.granite.ab.ca/access/autofe.htm
Bugs and Problems
StartMethod=AutoSelect does not work with ADP files. I will be
working on a solution to this problem sometime soon. I'd suggest
using version V1.65 for now. Email me if this is a problem and I'll
see what I can do.
Note that I have no idea when I will have the time to fix this
problem.
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Granite Fleet Manager http://www.granitefleet.com/
*******************************************************************
The following error occurred while attempting to determine the Access/Jet
version of the file 'V:\APPS\SSP\ssp.ade' (while attempting to use DAO
Version 3.6)
Error: 3343 Unrecognized database format 'V:\APPS\SSP\SSP.ade'.
---------- C:\AutoFE\SSP.ini--------------------
[Settings]
MainApp=c:\program files\SSP\ssp.ade
Server=V:\APPS\SSP
;ShortCut=V:\APPS\AutoFE\SSP.lnk
;CommandLine=/runtime
;Shell=C:\Program Files\Microsoft Office\Office10\MSACCESS.EXE
Lockout=No
LockoutMsg=Sorry, not allowed into the system right now.
CreateShortCutOnDesktop=No
;http://www.granite.ab.ca/access/autofe.htm
--------------------------------------------------------------------------------
Auto FE Updater Version: 1.65
Windows Version: Windows XP 5.1 build 2600 (Service Pack 3)
User: 123
Workstn: abc
--------------------------------------------------------------------------------
"Tony Toews [MVP]" <tto...@telusplanet.net> wrote in message
news:ct3a55dm8v6gkbqma...@4ax.com...
"SimeonD" <sim...@nospam.nospam> wrote in message
news:u%23RjBNHA...@TK2MSFTNGP04.phx.gbl...
>Btw, both versions work fine when I use mdb.
>But won't work when I use ADP or ADE.
Correct. That's because I can use DAO to determine the Access version
in which an MDB/MDE is created so I can tell which version of Access
that is installed on the client system to start. However I can't
use DAO to determine the Access version in which an ADP/ADE is
created.
I need to either figure out how to determine the version of an ADP/ADE
or to figure out a method of ignoring this logic for ADP/ADEs and
doing something a bit different.
>Ah, I actually had no StartMethod=AutoSelect in my original, and I still had
>the same problem.
But StartMethod=AutoSelect is the default. If you can use a
different method there that would also take care of the problem.
>Using 1.65, I get the message below.
Hmm, then I have no idea. I'll have to think about this a bit.
>I need to either figure out how to determine the version of an ADP/ADE
Hmm, there might be a way using ADO. Actually very similar to DAO
with slightly different syntax.
>
> "Tony Toews [MVP]" <tto...@telusplanet.net> wrote:
>
>>I need to either figure out how to determine the version of an
>>ADP/ADE
>
> Hmm, there might be a way using ADO. Actually very similar to DAO
> with slightly different syntax.
But, oh, isn't it so GREAT!!!!! that ADPs don't use Jet?
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
[Settings]
MainApp=c:\program files\SSP\ssp.ade
Server=V:\APPS\SSP
ShortCut=V:\APPS\AutoFE\SSP.lnk
Lockout=No
LockoutMsg=Sorry, not allowed into the system right now.
CreateShortCutOnDesktop=No
I realise you're a busy man, so extra thanks for you help on this. Do you
still need me to email you?
Btw, I read your blog most days, I wonder will this newsgroup post appear on
google.....
"Tony Toews [MVP]" <tto...@telusplanet.net> wrote in message
news:af9c55huucodukpa5...@4ax.com...
>I realise you're a busy man, so extra thanks for you help on this. Do you
>still need me to email you?
No.
>Btw, I read your blog most days,
Glad I have readers there too.
>I wonder will this newsgroup post appear on
>google.....
It should.
--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no private e-mails, please)
"SimeonD" <sim...@nospam.nospam> wrote in message
news:OHGb8dTA...@TK2MSFTNGP05.phx.gbl...
>>I need to either figure out how to determine the version of an ADP/ADE
>
>Hmm, there might be a way using ADO. Actually very similar to DAO
>with slightly different syntax.
Probably the hardest part will be to figure out ADO late binding. I'm
currently using DAO late binding so I don't care what version of DAO
the user has installed.
Hmm, I have a vague memory of someone posting that ADO version 2.1 is
the standard for an old version of ADO that works for newer versions.
What problem are you having with late binding of ADO? What specifically are
you trying to do?
> Hmm, I have a vague memory of someone posting that ADO version 2.1 is
> the standard for an old version of ADO that works for newer versions.
Not sure that's really relevant: all you should need is to use
CreateObject("ADODB.Connection") and so on.
>>>>I need to either figure out how to determine the version of an ADP/ADE
>>>
>>>Hmm, there might be a way using ADO. Actually very similar to DAO
>>>with slightly different syntax.
>>
>> Probably the hardest part will be to figure out ADO late binding.
>
>What problem are you having with late binding of ADO?
None yet because I haven't tried it.
>What specifically are you trying to do?
From a VB6 exe I want to open an Access ADP/ADE and determine the
version. The ADO equivalent of
MDBVersion = db.Properties("AccessVersion")
which is, I think,
CurrentProject.Properties("AccessVersion")
CurrentProject.Properties("Build")
I do not want to execute the ADP/ADE. I just want to read the
version.
Hmm, that was dumb of me. I found a bit of sample code and didn't
record it.
>> Hmm, I have a vague memory of someone posting that ADO version 2.1 is
>> the standard for an old version of ADO that works for newer versions.
>
>Not sure that's really relevant: all you should need is to use
>CreateObject("ADODB.Connection") and so on.
Geez, if it's that simple I'm going to feel like an utter idiot for
not investigating this a *LOT* sooner.
I've actually never used an ADP, but could you use Access Automation
somehow?
Something like
Dim appAccess As Object
Set appAccess = CreateObject("Access.Application")
appAccess.OpenCurrentDatabase "pathtofile"
No, wait, you can't, because you might end up opening too old a version of
Access. What about
Set appAccess = CreateObject("Access.Application.12")
If Err.Number = 429 Then
' No Access 2007: try Access 2003
Set appAccess = CreateObject("Access.Application.11")
If Err.Number = 429 Then
' No Access 2003: try Access 2002
etc.
>I've actually never used an ADP, but could you use Access Automation
>somehow?
>
>Something like
>
>Dim appAccess As Object
>
> Set appAccess = CreateObject("Access.Application")
> appAccess.OpenCurrentDatabase "pathtofile"
>
>No, wait, you can't, because you might end up opening too old a version of
>Access. What about
>
> Set appAccess = CreateObject("Access.Application.12")
> If Err.Number = 429 Then
>' No Access 2007: try Access 2003
> Set appAccess = CreateObject("Access.Application.11")
> If Err.Number = 429 Then
>' No Access 2003: try Access 2002
>
>etc.
Well, I don't want to startup Access as that would take a few seconds.
So I just want to use the builtin DAO/ADO libraries to get the
version.
BTW this is for the Auto FE Updater.
Yeah, I understand exactly what you're trying to do.
Here's late binding to create a connection to an access mdb and then write
out all of the properties of the connection:
Dim con As Object
Dim prp As Object
Dim strConnect As String
strConnect = "Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=C:\Folder\File.mdb;"
Set con = CreateObject("ADODB.Connection")
con.ConnectionString = strConnect
con.Open
For Each prp In con.Properties
Debug.Print prp.Name & " = " & prp.Value
Next prp
con.Close
Set con = Nothing
See whether there's anything useful for you doing that.
> con.Open
When I run the above against an ADP I get the following error:
?err.Number
-2147467259
?err.Description
Unrecognized database format 'Q:\1 access\testing\TestADO.adp'.
When I run it against an MDB I get all kinds of properties but nothing
at first glance that's useful.
I'll continue poking about though.
Hmm. That kind of makes sense. Given that an ADP strictly goes against SQL
Server, what relevance is the version of the ADP file?
>Hmm. That kind of makes sense. Given that an ADP strictly goes against SQL
>Server, what relevance is the version of the ADP file?
But it's available if you use CurrentProject so ....
Its from a project I had last year, to open an Access ADP from a third party
app. The idea was to open frmClient in Access, looking at a the same client
that was on screen in the third party app.
As far as I remember, my main problems were: (1) Determing if only access
runtime was available. (2) Finding out if the Access app was already open.
'********************************************************
' Get the nice style of the Access version name.
Public Function GetAccessVersionNiceName() As String
Try
Select Case GetAccessVersionNumber()
Case 8
Return "Access 97"
Case 9
Return "Access 2000"
Case 10
Return "Access XP"
Case 11
Return "Access 2003"
Case 12
Return "Access 2007"
Case Else
Return "unknown"
End Select
Catch ex As Exception
Return "unknown"
End Try
End Function
' Determine the Access version by creating an
' Access.Application object and looking at
' its Version property.
Private Function GetAccessVersionName() As String
Dim obj As Object = CreateObject("Access.Application")
Dim result As String = "Access.Application." & _
obj.Version
obj.Quit()
Return result
End Function
' Get the Access version number from the name.
Private Function GetAccessVersionNumber() As Integer
Dim txt As String = GetAccessVersionName()
Dim pos2 As Integer = txt.LastIndexOf(".")
Dim pos1 As Integer = txt.LastIndexOf(".", pos2 - 1)
txt = txt.Substring(pos1 + 1, pos2 - pos1 - 1)
Return CInt(txt)
End Function
"Tony Toews [MVP]" <tto...@telusplanet.net> wrote in message
news:n6tk555obhk6qtu65...@4ax.com...
>I'm a bit confused. Why does the version of the ADP or mdb matter?
>Is it not just the version of office?
I look at the version of the MDB to determine which version of Access
which is installed on the system to start up. Now granted it's
unlikely too many people will have multiple versions of Access but
that's how I set it up a while back.
In hindsight I should've figured out a means of getting around this
but there haven't been too many complaints.
>There is come code I use below, which determines the version of Access. Its
>VB 2005 though.
>Not sure if its any use, but its along the lines of what Doug was saying.
>
>Its from a project I had last year, to open an Access ADP from a third party
>app. The idea was to open frmClient in Access, looking at a the same client
>that was on screen in the third party app.
>As far as I remember, my main problems were: (1) Determing if only access
>runtime was available. (2) Finding out if the Access app was already open.
I want to use a method that does not require Access to execute until
it's required to run the MDB/ADP.
While I understand the desire for speed, opening Access using Automation
isn't the same as Access executing. Have you tried it? I suspect it'll be
fairly quick.
"Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_gmail.com> wrote in message
news:edB3x$$AKHA...@TK2MSFTNGP04.phx.gbl...
>Any update on this?
>Not trying to pressure you or anything.....
Regretfully not yet. And I likely won't have the time to look at this
for at least a few more weeks or longer.
Fair enough, I know you're a busy man. Thanks for letting me know
>>>Not trying to pressure you or anything.....
>>
>> Regretfully not yet. And I likely won't have the time to look at this
>> for at least a few more weeks or longer.
>
>Fair enough, I know you're a busy man. Thanks for letting me know
>
Please email me. I've been thinking on this one a bit and I think I
have a solution both overall and the appropriate API code. I'll see
where I can get today or the next few days on this one.