Text of Startup Option Application Title

  • Thread starter Thread starter Joseph Misko
  • Start date Start date
J

Joseph Misko

How do I get the text that I entered in the "Application Title" field under
Startup options?

Thanks,
Joe
 
Hi Joe

It is stored in a property of the database object named "AppTitle", so the
following expression will return it:

CurrentDb.Properties("AppTitle")

If you have not set that option, then the property will not exist and the
expression above will raise an error (3270 - property not found) which you
can trap.
 
Many thanks. I forgot to mention one caveat. My entire application makes
no explicit or implicit reference to DAO. If I use CurrentDb, the Access
help file states that this "adds a hidden reference to the DAO 3.6 Object
Library" which I was hoping to avoid. Is there any other method? If not, I
will go with it.

Thanks,
Joe

Graham Mandeno said:
Hi Joe

It is stored in a property of the database object named "AppTitle", so the
following expression will return it:

CurrentDb.Properties("AppTitle")

If you have not set that option, then the property will not exist and the
expression above will raise an error (3270 - property not found) which you
can trap.

--
Good Luck!

Graham Mandeno [Access MVP]
Auckland, New Zealand

Joseph Misko said:
How do I get the text that I entered in the "Application Title" field
under Startup options?

Thanks,
Joe
 
Hi Joseph

If this is an ADP then I think you use CurrentProject instead:
CurrentProject.Properties("AppTitle")

However, this does not work in an MDB/MDE. I can't see why you would want
an MDB/MDE without a reference to DAO, because that is the native object
model.

--
Good Luck!

Graham Mandeno [Access MVP]
Auckland, New Zealand

Joseph Misko said:
Many thanks. I forgot to mention one caveat. My entire application makes
no explicit or implicit reference to DAO. If I use CurrentDb, the Access
help file states that this "adds a hidden reference to the DAO 3.6 Object
Library" which I was hoping to avoid. Is there any other method? If not,
I will go with it.

Thanks,
Joe

Graham Mandeno said:
Hi Joe

It is stored in a property of the database object named "AppTitle", so
the following expression will return it:

CurrentDb.Properties("AppTitle")

If you have not set that option, then the property will not exist and the
expression above will raise an error (3270 - property not found) which
you can trap.

--
Good Luck!

Graham Mandeno [Access MVP]
Auckland, New Zealand

Joseph Misko said:
How do I get the text that I entered in the "Application Title" field
under Startup options?

Thanks,
Joe
 
Good question. I eliminated all references to DAO and have used ADO, but
since my interface and tables are all Access MDB it raises the question of
whether ADO is better or newer or whether DAO is the way to go. Any input?

Thanks!

Graham Mandeno said:
Hi Joseph

If this is an ADP then I think you use CurrentProject instead:
CurrentProject.Properties("AppTitle")

However, this does not work in an MDB/MDE. I can't see why you would want
an MDB/MDE without a reference to DAO, because that is the native object
model.

--
Good Luck!

Graham Mandeno [Access MVP]
Auckland, New Zealand

Joseph Misko said:
Many thanks. I forgot to mention one caveat. My entire application
makes no explicit or implicit reference to DAO. If I use CurrentDb, the
Access help file states that this "adds a hidden reference to the DAO 3.6
Object Library" which I was hoping to avoid. Is there any other method?
If not, I will go with it.

Thanks,
Joe

Graham Mandeno said:
Hi Joe

It is stored in a property of the database object named "AppTitle", so
the following expression will return it:

CurrentDb.Properties("AppTitle")

If you have not set that option, then the property will not exist and
the expression above will raise an error (3270 - property not found)
which you can trap.

--
Good Luck!

Graham Mandeno [Access MVP]
Auckland, New Zealand

How do I get the text that I entered in the "Application Title" field
under Startup options?

Thanks,
Joe
 
Hi Anthony

This is a quote from Mary Chipman, SQL Server MVP, ex-Access MVP, and author
of several excellent books including "Microsoft Access Developer's Guide
to SQL Server".

I think it answers your question better than I could :-)

===========================================
DAO was designed, customized, and tweaked specifically for the Jet
engine. In an all-Access application, it will give you the best
performance and the most complete feature set. It will undoubtedly
continue to be supported as long as Jet ships as a database engine for
Access. If you only program in Access against Jet, you probably won't
ever need ADO.

ADO was designed as a general-purpose data access wrapper around OLE
DB and is not specific to a particular engine. If your Access
application makes use of SQL Server data, then ADO will be a better
choice when writing data access code (and is in fact used in an ADP
where the Jet engine isn't present). DAO uses the Jet engine, which
adds unnecessary overhead when coding against SQL Server, etc. If for
some reason you can't use ADO, then ODBCDirect is a better choice when
coding against SQLS because it bypasses Jet.

You don't need to worry about learning ADO.NET unless you're building
a VS.NET windows forms or an ASP.NET app, because it doesn't work in
Access or any other COM apps--it requires the .NET Framework. The
other developers you spoke to are right--ADO.NET is really a new and
different technology that bears only a superficial resemblance to
classic DAO/ADO. However, you still may need to learn ADO if you land
a project that isn't being built using .NET -- VB6 will undoubtedly be
around for years to come.

Yes, the alphabet soup of data access technologies is confusing -- but
there's sound technical reasons why you'd choose one data access
method over another in a given situation.
============================================

--
Good Luck!

Graham Mandeno [Access MVP]
Auckland, New Zealand

Anthony Bollinger said:
Good question. I eliminated all references to DAO and have used ADO, but
since my interface and tables are all Access MDB it raises the question of
whether ADO is better or newer or whether DAO is the way to go. Any
input?

Thanks!

Graham Mandeno said:
Hi Joseph

If this is an ADP then I think you use CurrentProject instead:
CurrentProject.Properties("AppTitle")

However, this does not work in an MDB/MDE. I can't see why you would
want an MDB/MDE without a reference to DAO, because that is the native
object model.

--
Good Luck!

Graham Mandeno [Access MVP]
Auckland, New Zealand

Joseph Misko said:
Many thanks. I forgot to mention one caveat. My entire application
makes no explicit or implicit reference to DAO. If I use CurrentDb, the
Access help file states that this "adds a hidden reference to the DAO
3.6 Object Library" which I was hoping to avoid. Is there any other
method? If not, I will go with it.

Thanks,
Joe

Hi Joe

It is stored in a property of the database object named "AppTitle", so
the following expression will return it:

CurrentDb.Properties("AppTitle")

If you have not set that option, then the property will not exist and
the expression above will raise an error (3270 - property not found)
which you can trap.

--
Good Luck!

Graham Mandeno [Access MVP]
Auckland, New Zealand

How do I get the text that I entered in the "Application Title" field
under Startup options?

Thanks,
Joe
 
Back
Top