Hi Falcus,
Good technical points here... Yes, TS12 will only see up to 4GB maximum of RAM as this is a 32-bit application. Windows 7 and up will allocate this much to any 32-bit application no matter how much RAM is installed on the system. This is part of the 32-bit APIs used in he operating system, and allows these applications to co-exist on a 64-bit platform. T:ANE is going to be a full 64-bit application so it can work with as much RAM as the system can throw at it and will therefore have many, many more resources than we are using now.
Yes, databases will take a beating for some time. I've seen that with big MS_SQL and Oracle databases. They have built-in data recovery through transaction logging so they can "playback" and restore missing parts. This as you said can go on just for so long before something gets totally wrecked. In our case we see lock ups with the application, which if you read my post I noted well. The fact that my data corruption was caused by ailing hardware eventually destroyed some assets. I've been able to go through my non-built-in items by opening them for edit and then closing them again. The ones I couldn't open due to errors, or could be committed again, were replaced with fresh ones.
Windows Vista, actually Windows NT 4.0 and up as I should say, has journaling built into it to help recover data. This is kept in the Master File Table (MFT) which is divided into two parts - directories and files. Windows also does a lot of caching with such processes as disk access and directory structure building. This is why it's not good to turn off or reset systems while the drive is being written to. Things can really go down hill really fast if this is done one time too many. The current iterations of the operating system; Windows 7 and Windows 8.xx have another layer of resiliency built into it. This too actually started with Vista as well, but has been more refined. I believe this is what you were referring to, and this will eat up a ton of disk space. Every file that is opened and changed, is copied and saved to the volume store. This acts as a safety net and files can be restored should they be corrupted. Whether this is operating system-controlled or application controlled I don't know as I've never made use of this technology myself to find out.
The problem as you've noted is partly the database size, which grows exponentially as routes are installed. The ever constant search of dependencies brings more and more data down whether we actually need that or not. Combine that with our own activities, and we have pretty full hard disks very fast. This additional data does slow things down, and sometimes badly. To help mitigate this problem, I run regular drive defragmenting sessions as well as prevent the antivirus program from scanning and accessing the Trainz data folders. This latter process does help with the access due to less interference by the antivirus program on the data, and the defrag has helped considerably as well particularly when doing work in Surveyor and Content Manager due to the data manipulation as we search for content.
This however, doesn't solve the crashing which many of us have experienced. As we've all stated before, and have been through the mess, the best thing to do when Trainz is in a snit is to leave it alone and let it recover.
John
Good technical points here... Yes, TS12 will only see up to 4GB maximum of RAM as this is a 32-bit application. Windows 7 and up will allocate this much to any 32-bit application no matter how much RAM is installed on the system. This is part of the 32-bit APIs used in he operating system, and allows these applications to co-exist on a 64-bit platform. T:ANE is going to be a full 64-bit application so it can work with as much RAM as the system can throw at it and will therefore have many, many more resources than we are using now.
Yes, databases will take a beating for some time. I've seen that with big MS_SQL and Oracle databases. They have built-in data recovery through transaction logging so they can "playback" and restore missing parts. This as you said can go on just for so long before something gets totally wrecked. In our case we see lock ups with the application, which if you read my post I noted well. The fact that my data corruption was caused by ailing hardware eventually destroyed some assets. I've been able to go through my non-built-in items by opening them for edit and then closing them again. The ones I couldn't open due to errors, or could be committed again, were replaced with fresh ones.
Windows Vista, actually Windows NT 4.0 and up as I should say, has journaling built into it to help recover data. This is kept in the Master File Table (MFT) which is divided into two parts - directories and files. Windows also does a lot of caching with such processes as disk access and directory structure building. This is why it's not good to turn off or reset systems while the drive is being written to. Things can really go down hill really fast if this is done one time too many. The current iterations of the operating system; Windows 7 and Windows 8.xx have another layer of resiliency built into it. This too actually started with Vista as well, but has been more refined. I believe this is what you were referring to, and this will eat up a ton of disk space. Every file that is opened and changed, is copied and saved to the volume store. This acts as a safety net and files can be restored should they be corrupted. Whether this is operating system-controlled or application controlled I don't know as I've never made use of this technology myself to find out.
The problem as you've noted is partly the database size, which grows exponentially as routes are installed. The ever constant search of dependencies brings more and more data down whether we actually need that or not. Combine that with our own activities, and we have pretty full hard disks very fast. This additional data does slow things down, and sometimes badly. To help mitigate this problem, I run regular drive defragmenting sessions as well as prevent the antivirus program from scanning and accessing the Trainz data folders. This latter process does help with the access due to less interference by the antivirus program on the data, and the defrag has helped considerably as well particularly when doing work in Surveyor and Content Manager due to the data manipulation as we search for content.
This however, doesn't solve the crashing which many of us have experienced. As we've all stated before, and have been through the mess, the best thing to do when Trainz is in a snit is to leave it alone and let it recover.
John