Database and DNS

[PK Player]

Hello

We have recently undergone a network upgrade and now have a couple of servers, each hosting three virtual machines.

We have a database that has been hosted on two successive servers, both named Orion. The second server named Orion still exists as a physical machine, and while all other data has been moved off it to one of the VM's, the database remains on it.

The database front end (I am not a database person so, please ask if you need further info) references the individual DB's via a UNC path \\orion\database\...

The server we wish to move the database to has a different name. My question is how to maintain the integrity of the paths while hosting it on a server with a different name.

The consultancy who oversaw the network upgrade suggested adding a DNS A Record named Orion which points to the IP address of the new server. I have done some research and discovered this is fine so long as there is only one PTR record that resolves to the server's true name.

None of us is familiar with Access, and this database is over 20 years old but keeps chugging along (it was created in 1998). We dare not tinker with it as we don't have the expertise. It hosts information about our clients and the projects we have managed over the years (comprising several thousand records). Also, because the powers that be are reluctant to pay for a database professional to upgrade it we are forced to use Access 2003 to open it. We have Office 2016 installed, but Access 2016 won't recognise databases created in versions of Access earlier than 2003 (we see blank boxes where data should be). This last snippet may not be relevant but I've included it in case it affects how the data move is accomplished.

Considering these constraints, is the DNS route the best way forward? My plan was to move the data to the new server, remove Orion from the domain, rename it, delete the old A Record for Orion, then create a new one that points to the IP address of the VM that will be hosting the database data (un-ticking the option to create a corresponding PTR record). I don't know how Access works when connecting to a database on a server - for example, I don't know if it does a PTR check (which would fail).

Does anyone have any thoughts, advice etc., about this, please?

Thank you.

[#2]

@PK Player Without further knowledge of your network and related...i dare to say that something is wrong all along.

Why would you mess with the DNS for a simple Connection change...just replace the linked table path and that's all...IF you fall in the case that you have Linked Tables :

If you hover your mouse over one of the linked table you should see something like

\\Orion\TheShareName\theBE.mdb

On the other hand...you said that the application is from 1998 ...so probably was made in Access 97...now Access normally cannot "link" to such as older version ....(well it can but it involves some trickery...check my Article on EE : https://www.experts-exchange.com/articles/33729/Importing-Tables-from-Older-Unsupported-Access-datab... ...but in this case you should have probably NO Linked tables and everything is controlled by code).

It seems like an "interesting" ...so if you could upload some screenshots probably i could assist some more.

Probably ...it would it be as easy as using my utility to pull the records to a new database (it does that...just follow my Article) ...and use the New Table Manager to relink your FE to the new BE...

[#3]

@tsgiannis 

Thank you. I really appreciate your response and on the surface, it looks like it will do what we need. However, none of us is familiar with Access and we do not understand how this might impact the DB. If it was a simple database I would go with it, but if anything happens and it crashes etc., it would be a disaster.

I think I may just create a new Windows 10 client with the name Orion and have done with it. It will split our data over to another machine (which I was hoping to avoid once the original \\Orion was decommissioned) but it may be the best way forward.

Thanks again.

[#4]

@PK Player The most essential thing to do is to take a rock solid backup...after that you can play safely.

[#5]

@PK Player 

If the database is so important, then why not hire someone with some skills in Access to upgrade your database? It will cost you maybe up till 200 dollar and your problem is solved. 

Probably if you would create a new empty database in Access 2016 and import everything from the old database in the new with the "wizzard"   I think everything would work like a charm in a new version. Advantage from trying this is that you are not have any risc to loose anything. 

If it does not work I can suggest some more possible solutions. 

Greetings,

Marcel

[#6]

Thanks for the suggestion. I am in a difficult situation because the person who can resolve this by releasing funds to upgrade and modernise the 20+ year-old database is of the opinion that it works so why pay for someone to do that. Prices for the overhaul vary between £600 - £900. I have tried to get it upgraded several times over the last ten years. It is frustrating.

Also, while the database 'works', it really does need to be dragged into the modern era. It was created in 1997-1998, and a front end for the various elements was designed in 1999. Minor tweaks have occurred since that time. The person who designed the front end (an Access professional) reportedly took one look at the underlying structure, shuddered, and just stitched it together because it would have taken a looooong time to clean it up.

I am going to add the A records to our new server and use it from there. I'll just have to keep my fingers crossed that nothing happens to it. We've got backups of the database files so restoring it isn't an issue.

Thanks again for the help.

[#7]

@PK Player without knowledge of the structure and the inner working of your database i think the prices are a bit high...as suggested for around 200 it would be just fine