I have been getting some strange errors in a couple places in the access application. I mostly ignored the errors for the first few days, but eventually followed the recommendation to see if a reference to a file that was missing was causing the other problems.
The error message looked like this:
Following this error lead me into the VB editor under Tools | References, where I found the reference to the missing file (which had been refactored in the newer version of access 2007 which i was using).
Once I removed the reference to the missing utility.mda file, the errors cleared right up.
I am a little tired of typing in a password to access this DB.
I am using access 2007. Upon launching the application and clicking on Database Tools, I saw the Set Database Password option and clicked it. Access informed me that I had to have the DB opened in exclusive mode before I could remove the password.
I closed the DB and launched Access, without having opened the DB. I went to File open and looked for the option to open the DB exclusively. It took me a couple minutes to notice the little dropdown arrow in the bottom right corned of the form. Once I browsed to and highlighted my DB, the open exclusively was avail.
With the DB opened exclusively, I was able to remove or set a new password.
I have linked tables in my access project. When I want to control the location of the linked DB, I can do that by selecting from the Database Tools | Linked Table Manager.
This brings up a dialog with all of the linked tables. The current location of the linked tables will display next to each linked table. Click the Select All button and then click OK, to test if the linked tables are actually linked.
I have a ms access application that I am now supporting. It consists of two dbs. One stored the application code, objects and references or links to another db that stores the data. The model makes sense. For benefit of this post
td = the DATA db on the network drive
tc = the CODE db stored on a workstation
There are two workstations that the customer uses to access tc, which consumes from td.
I have been attempting to create a 3rd workstation to house the tc. I am trying to get the 3rd workstation to connect or recognize td on the share drive.
I have access to the share drive and have created a mapping to it. It is a Novell drive. I can browse to the drive with no issue. I should note that I am using Windows XP. I can browse to the novell drive and can see the td DB. I can open the td DB.
It is the tc DB that contains the references or links or contains references to linked tables in td.
I am using Access 2007 and have opened tc and attempted to compile or run the application. It is written in VBA and contains a autoexec macro that loads the application. One of the very first tasks it tries to carry out is connecting to the linked tables in td. I can look in a module called Attach_Tables and see some code there but have to this point been unsuccessful in getting the tc application to look anywhere but a specific location mentioned by the application. It is like there is a hard coded value somewhere that is forcing tc to look for td in a very specific location. I can get the application main menu to load and when clicking on a button, loads another form. Great, the application is executing ok, but anytime in needs to speak to td for data, it complains any says “drive:\path\dbname”. is not a valid path.
I am sitting in tc and have clicked on Database Tools | Linked Table Manager and can see the linked tables that are defined in td. Ah, seeing the path (visuals are amazing) made me realize my mapping was incorrect. I was one folder too deep. Once I updated my novell mapping, and refreshed the linked tables, I was in Business!
What I need to do now is FIGURE OUT HOW TO CHANGE THE PATH in the tc db. I need to be able to experiment with the data, make new rows, remove rows etc. I need to make a practice copy and change the path, or actually leave the path the same, just make a copy of the td db, call it tdcopy.mdb and place it in the same folder as the td db. Then, find the variable or procedure that is defining the path, and change it to tdcopy.mdb.
That way, I AM NOT WORKING IN THE ACTUAL td db.
This is interesting
http://support.microsoft.com/Default.aspx?kbid=210062
The data db sits on a shared network drive, while the
I meet again with my customer yesterday. I went to get copies of the two dbs to put on my thumb drive so I could look at them. The code db is stored locally on two computers. I will only think of this as a single computer, since the changes that I will make in this DB will be simply copied to the other computer. The intention according to my customer was to only have the code DB in a single place, but there are 4 other people who use the computer, so they copied it to another location.
The code db is the the one that is launched, contains the front end form and the other forms, queries and reports and other assets. The code DB links or connects to the data db, which houses all the data.
I AM NOT SURE WHY THERE ARE SEPARATE DBs for the code and data?
What we need to do is MOVE THE code db to the network drive and store it with the data DB. Whatever the issue is with trying to store the code db on the network needs to be resolved!
Then I can work on the code DB in a single location.
I think I need to get access to the share drive (Novell) where the DBs are located so I can set up a copy of each and try to get it to work correctly from their.
I think these are my steps….
get access to the share drive
create a copy of the data db on the share drive, in the same location (folder)
rename the copy to estecdata2.mdb
copy the code db to the share drive, in the same folder (i will need to work on getting the two DBs talking to each other in the same location)
rename copy to esteccode2.mdb
Once the data and code DBs are in place on share drive and talking to each other
Find what the problem is that has kept this solution from working.
I need to run this thinking past my coworker….he is sometimes helpful. he may have a little history around the problem with trying to share on the same drive.
I need to share my thinking with my customer, tell her that i want to get this model setup first, and then work on specific issues.
Once I have this model compete, I will update both of the workstations where the system is accessed from. Put a shortcut on the desktop to the code DB – which points to and consumes the data DB.
Look what I found.
I opened the code DB, browsed Database Tools | Visual Basic and found all the goodies.
I have just spend about 1/2 hr looking through the various Form and Report objects located in the code db. Lots of VB here, this is where most of the work is being done. The Form objects include local definitions of data, form elements, procedures and SQL code to speak to the data db.
My VB is very rusty, but the overall complexity of the project does not seem too bad. As long as I can figure out what is being called, what is invoking the call, and pause, dump and break the execution to test things out along the way, I should be fine.
I meet with a new customer the other day who is using a 10 year old (at least) MS access DB. The current version is 2003. We meet for a couple hrs, with my client giving me the grand tour of the “science kits” area. Interesting stuff. She and 4 others work in support of a number of school districts, providing science kits for various units of study. There are a lot of the kits and a lot of variation of the contents of the kits.
The DB supports the inventory, distribution, location etc. of the kits.
My customer walked me through the application, showing me how it works, what it does, what it is supposed to do, but does not.
There is a lot of old data in the DB, teachers, school districts and kits that should be removed, but cannot because of referential integrity rules. For example, we cannot remove an old district building because there is an association with the id of that record in another table somewhere.
There are buttons that do not completely perform actions.
There are actions that are performed, but incorrectly.
There are forms that do not display data.
There are reports that are missing data.
There are calculations that are not correct.
There are calculations that are not complete.
There are forms that have buttons that do nothing, are not necessary.
The application also generates mailing labels that are used on the kits when they are shipped to districts.
There is a bit of date calculation that goes on. Especially with return dates, due dates, based on starting dates.
Instruction materials processing center!
More more more to follow….
Today, I finally deployed my first compiled .swf file to our production server. Over the past few weeks, I have been working on getting a local setup to mirror a production environment. This is not a trivial task when flex is involved. The short of the story is I finally got FlexBuilder 3, ColdFusion 10 and MSSQL Server 2005 working together. Today, I performed the following steps deploying a slightly upgraded .swf.
1 – Updated a couple text strings on buttons, a message on the opening form.
2 – Recompiled the flex project.
3 – Opened a window to the output path in my Coldfusion webroot (that’s where the compiled .swf and html files are written).
4 – Opened a connection to the production server – using windows explorer, authenticated to open the window.
5 – Launched the live application in a web browser
6 – Renamed the existing .swf file, appending the date to the end of the name, like: name_7_6_12.swf
7 – Refreshed the browser and saw the live application not load, as expected
8 – Copied the newly compiled .swf with the same name as the one I just renamed to the same location as the renamed .swf.
9 – Reloaded the browser and the application popped back to life with the newly deployed .swf in action.
The reason I rename the existing .swf on the live server was in case I had a problem with the remoting between flex and Coldfusion. I was not completely sure that would work as expected. This way, if I had a problem, I would remove the new .swf and remove the date from the renamed .swf and be back in business.
The last step involved will be checking in the two updated .mxml files into the SVN repository.
The end.
