Selling a DB

DavidWRouse

Registered User.
Local time
Today, 04:21
Joined
Jul 24, 2003
Messages
42
I am planning on creating a package that i plan to sell via adverts in specialist magazines.

I would like to create the Package in Access and distribute it as a stand alone item to people who do not have access.

1) Is this feasable?
2)Will i have to pay MicroSoft
3)WIll i need Access Developer
4)Will it be secure enough

I have loads of questions that i would like to answer before I start to create the package.

Does anyone know where I can read up on this subject??
 
1.) Yep - feasible
2.) No, you wont have to pay Microsoft
3.) Yes - you will need the Developer Edition so that you can package your application with Access Runtime so it is not dependant on users have MS Access on their machines.
4.) It will be as secure as you make it! :) There are many steps you can take to secure a db (make .mde, user - level security, disable bypass keys, etc... Search the forum for keywords like "Security", "Secure an Access db", and such for more info on the topic...

HTH,
Kev
 
Thanks for the feedback.

That was just the answers i was hoping to get.

I will try to get hold of Access Developer
 
Given the known problems with developer, you might be better off just selling your db to those with Access already installed
 
Make sure you check out the limitations of Access runtime before going down the Office developer route.
 
Pat,

Regarding the "Start/Run" box you mention...Is that same as the "Target" path on the "Shortcut" tab of the properties dialog box?

I currently have a database that utilizes access-level security that references a WIF that has to be opened using a shortcut on the user's desktop...and just inserted the " /runtime " at the end of this shortcut path and it apparently opened as usual after requesting the usual password...however, I havent noticed any differences in the operation of the database and was wondering if I did this correctly.

FYI: I have made my db essentially totally button-driven with switchboards...so I dont know if I would notice any diff anyway.

Thanks for any info.
 
This is just pasted from another post but it still applies...



Deploying Microsoft Access Applications using the Access Runtime:

http://msdn.microsoft.com/library/d...pplications.asp

Deploying Complex Microsoft Office Access Runtime-Based Solutions - Access 2003:

http://msdn.microsoft.com/library/d...acdeployade.asp

In this section, you'll find links to technical articles, developer documentation, resource kits, book excerpts, support centers, and more for the previous two versions of Microsoft Access.

http://msdn.microsoft.com/office/pr...ss/default.aspx

As a new developer in Access I am continually learning... I haven't personally distributed a runtime environment yet (basically being lazy), but I have distributed mdb and mde files... all of which react differently on different computers even though they have identical software on them. That's where the fun is... making sure your app will react the same on as many computers as possible, especially when you start to code on particular environments.
Use the latest and best version that you can afford.
In Office 2003, Microsoft no longer has a developer version of MS Office, but they have Developer Tools in which you can purchase seperately.
According to other various resources, this should be the last version of Access (2003) that supports the jet database and that the .Net environment will be incorperated in the future versions of MS Office.

A hunch... that the next Access version will use the Microsoft SQL Server 2000 Desktop Engine.

As stated above in the other replies... securtiy is a main concern with the jet database. Take their advise to heart.
 
How would one convert a traditionally split database solution, i.e. MDE front end and MDB backend for network sharing, into a runtime Access solution.

Does Developer have support for this? I would be very interested if I could deploy our database to systems without Access via Developer, but would need to be able to maintain backend access via the network.

TIA
 
Last edited:
Pat Hartman,

The menu I have is the default menu you get when you disable at startup...and I can still print everything as normal...I use no macros.

I have discovered that this "/runtime" feature has increased the performance speed of my forms/reports 8-10 times...the entire office loves it...

I know this feature is used to demo the runtime environment, but obviously has enhanced the performance of my db...

Can I expect any other anomalies or problems other than what you have mentioned or can think of?

Thank you.
 
I have discovered that this "/runtime" feature has increased the performance speed of my forms/reports 8-10 times...the entire office loves it...

Interesting... I would have thought performance would go the opposite direction on this... Anyone else have any input as to why the use of the runtime version is performing tasks faster or is this an isolated case where this developer has triggered something resulting in better performance...

Thoughts?
Kev
 

Users who are viewing this thread

Back
Top Bottom