Solved!
Go to SolutionMSSQL DB failure
Hi expert..!
We had a SQL DB failure for the (standalone) client. when we keep the DB name in the save set manually the backup will fail for the particular database with the below error.
. when we keep the DB name in the save set as default that is MSSQL that backup is getting successfully. (PFA)
Kindly help us to fix
832
0
Posted December 26th, 2022 05:00
Hi experts..!
kindly help me with this..!
735
0
Posted January 5th, 2023 00:00
MSSQL:msdb MSSQL:model MSSQL:master MSSQL:Voucher MSSQL:UserSettings_Dealer MSSQL:UserSettings_ClickOnce MSSQL:UserSettings_Citrix MSSQL:TRANSACTIONS_RUS_LONGTIME MSSQL:TRANSACTIONS_LTH_LONGTIME MSSQL:TRANSACTIONS_LAT_LONGTIME MSSQL:TRANSACTIONS_FIN_Dealer_LONGTIME_2022 MSSQL:TRANSACTIONS_FIN_Dealer_LONGTIME_2021 MSSQL:TRANSACTIONS_FIN_Dealer_LONGTIME_2020 MSSQL:TRANSACTIONS_FIN_Dealer_LONGTIME_2019 MSSQL:TRANSACTIONS_FIN_Dealer_LONGTIME_2018 MSSQL:TRANSACTIONS_FIN_Dealer_LONGTIME_2017 MSSQL:TRANSACTIONS_FIN_Dealer_LONGTIME_2016 MSSQL:TRANSACTIONS_FIN_Dealer_LONGTIME_2015 MSSQL:TRANSACTIONS_FIN_Dealer_LONGTIME_2014 MSSQL:TRANSACTIONS_FIN_Dealer_LONGTIME_2013 MSSQL:TRANSACTIONS_FIN_Dealer_LONGTIME MSSQL:TRANSACTIONS_FIN_Company_LONGTIME_2022 MSSQL:TRANSACTIONS_FIN_Company_LONGTIME_2021 MSSQL:TRANSACTIONS_FIN_Company_LONGTIME_2020 MSSQL:TRANSACTIONS_FIN_Company_LONGTIME_2019 MSSQL:TRANSACTIONS_FIN_Company_LONGTIME_2018 MSSQL:TRANSACTIONS_FIN_Company_LONGTIME_2017 MSSQL:TRANSACTIONS_FIN_Company_LONGTIME_2016 MSSQL:TRANSACTIONS_FIN_Company_LONGTIME_2015 MSSQL:TRANSACTIONS_FIN_Company_LONGTIME_2014 MSSQL:TRANSACTIONS_FIN_Company_LONGTIME_2013 MSSQL:TRANSACTIONS_FIN_Company_LONGTIME MSSQL:TRANSACTIONS_EST_LONGTIME MSSQL:RetroSbManagementDb MSSQL:RetroSbGatewayDatabase MSSQL:RetroSBMessageContainer01 MSSQL:Retro MSSQL:ReportServerTempDB MSSQL:ReportServer MSSQL:RETRO_Report_RUS MSSQL:RETRO_Report_LTH MSSQL:RETRO_Report_LAT MSSQL:RETRO_Report_FIN_Dealer MSSQL:RETRO_Report_FIN_Company MSSQL:RETRO_Report_EST MSSQL:Nesta MSSQL:NAPA MSSQL:Mobpay_Prod MSSQL:EttteplanMoreLog_TSS MSSQL:EatechSettings_EUS_POS_FIN MSSQL:EatechSettings_EUS_FIN MSSQL:EatechSettings_EUS_BR_RUS MSSQL:EatechSettings1.1 MSSQL:EatechSettings MSSQL:EatechLog_SufficiencyTracker MSSQL:EatechLog_StationEventLog MSSQL:EatechLog_RomuWebService MSSQL:EatechLog_RomuAlarmer MSSQL:EatechLog_RetroWebService_Dealer MSSQL:EatechLog_RetroWebService MSSQL:EatechLog_RetroMonitoringService MSSQL:EatechLog_RelaySendService MSSQL:EatechLog_PriceTrackerService MSSQL:EatechLog_PosManagerImport MSSQL:EatechLog_PAFWebservice MSSQL:EatechLog_MobPay MSSQL:EatechLog_LogDataService MSSQL:EatechLog_IntegrationService MSSQL:EatechLog_InfomasterTicketService MSSQL:EatechLog_HtmlRetroWebService_Dealer MSSQL:EatechLog_HtmlRetroWebService MSSQL:EatechLog_FileDistributor MSSQL:EatechLog_EUS_POS_FIN MSSQL:EatechLog_EUS_FIN MSSQL:EatechLog_EUS_BR_RUS MSSQL:EatechLog_EUSFileSyncServer_BR_RUS MSSQL:EatechLog_EUSFileSyncServer MSSQL:EatechLog_EUSFileImport509 MSSQL:EatechLog_EUSFileImport388 MSSQL:EatechLog_EUSFileImport MSSQL:EatechLog_DynamicMaintenanceService MSSQL:EatechLog_ControlMessageService MSSQL:EatechLog_ControlMessageFileService MSSQL:EatechLog_BlacklistServer MSSQL:EatechLog_AlarmSystem MSSQL:EatechLog_ATAPTransfer MSSQL:EUS_IntegrationServicePersistence MSSQL:EUS_IntegrationServiceMonitoring MSSQL:EUSStorage_POS_FIN MSSQL:EUSStorage_FIN MSSQL:EUSStorage_BR_RUS MSSQL:Blacklist_FIN MSSQL:ATAPTransfer_RUS MSSQL:ATAPTransfer_FIN MSSQL:
barry_beckers
393 Posts
659
0
Posted January 9th, 2023 10:00
based on the error it seems to cut off the .1 from the MSSQL DB MSSQL:EatechSettings1.1?
What was exactly mentioned in the client's saveset field? Copy/pasting things into there, might indeed have entered something that isn't visible?
Then again I see that the client runs nmm 9.0.1? That is pretty old and unsupported at that.
Might it not be time getting into supported territory again?
No idea if that very, very, very early nw9.0 version might even have had an issue dealing with MSSQL db's wit a "." (dot) in their name?
If it is the only DB that is failing, an easy test would be if also another DB was introduced that also has a .1 in its name to see if that has the same issue? Should be fairly easy to test by adding a more or less empty additional DB. Even on a test system.
If updating NW and NMM is out of the question, one might try renaming the DB (which might even be more cumbersome).
Is it even necessary to specify the DB instead of simply using MSSQL: instead? Why do you want or need to specify the DB's even? As deleting one would cause the backup to fail, while when adding one, it would not end up in the backup?