Screwed up my Database - Need to restore older version

yosiasz (Tito?)
I wanted to express my thanks very publicly.
Thanks to your private coaching, I was able to get back to the October 17 version of my database. You're a lifesaver!!
Only 2 obvious issues:
1.) Not certain mail "attachment" made the journey back. Presumably, they are linked elsewhere? or I have to enable some switch?
2.) I would like to be able to able to recover everything (mail, events, new records) that occurred since 10/17/18 until the current date. I believe there's a relatively "simple" way to do it but, I can't 'figger it.
Any additional free advice appreciated.
PS: Yes, I immediately backed up my data files and over this weekend I'll try to implement procedures I should have had in place for the last 3 years.

Thanks again,
Jim Gunther

on 1 & 2, not sure what you are talking about Jim
Is this SQL related?

I think so. (I have to spend some more time verifying)
1.) That is, it "appears" that links to attached items (ie e-mail attachment) did not show up in the restored 10/17 database. Not a bid deal really - the attached items are in a totally different folder....Presumably, the links that "connect" to said attachments are missing (or, maybe, they are in a separate folder within SQL??)
2.) I THOUGHT I read somewhere that I could identify records "touched in any manner" since 10/17 and bring them over to the updated version of 10/17 DB that I intend to continue using.
BTW: Finding a solution to #1 or #2 is NOT mission critical. I could manually reconstruct anything needed between 10/17 and today (11/21).

I think this has to do with relative path?? Do you have an application or a front end for this database?

Were the emails and email attachments themselves being saved in SQL Server or were they being saved on disk but the SQL table(s) was pointing to them ie

create table #riskmanagement(id int, email varchar(25), attachmentpath varchar(50) )

insert into #riskmanagement
select 1, '', 'c:\hag\excel.xls'

select * From #riskmanagement
id email attachmentpath
1 c:\hag\excel.xls

strong text The e-mail attachments themselves are saved in a separate (non-SQL) folder but - I THOUGHT - the linking "device" might be stored within SQL (with the body of the e-mail.

Every post from you is like a new surprise gift :joy::rofl: what is this device you talk about.
When was the last time you went on a good vacation?

Vacation??? I'm not familiar with that concept...<G>.

Seriously, when using word "device"I was referring to manner in which emails received by my CRM program might LINK attachments which are stored in a folder separate from the SQL data.

I have been assuming that such email capability and links reside within my SQL data (or is that outside the scope of SQL?)


>> yosiasz
>> November 21
>> Every post from you is like a new surprise gift what is this device you
>> talk about.
>> When was the last time you went on a good vacation

Check crm configuration/manual/help to see where default email attachments are stored. It could be saving them to sql or local folder on c drive? but I would assume depends on configuration of CRM. Or maybe crm has paid support?
Is this a online saas service or installed locally, I assume local install

Well - this is not really the case and becomes a bit more difficult but would be doable if you know and understand the tables and relationships within the database.

To get that data back - you would have to have a copy (backup) of the database after those values were added. If this data existed in the database after the merge/purge process - and you have a valid backup of that database that can be restored as a different name - then maybe you could find the information in the tables and reconstruct it...

Probably would be less time and effort to reconstruct the data from whatever other sources you have at this point - considering that most likely the data that you are looking for was purged.

SQL does not have folders - it has tables. There is probably a table that points to the location of the attachments. In most systems there is a table that identifies the location - and a separate table that identifies the attachment file name. If the location is defined as C:\EmailAttachments in the table and the actual location is D:\Attachments then the CRM would never find the files.

That is most likely configurable within the application - and you should be able to change it in the settings to identify where the system should look for the attachments. Update that to the correct new location and the system should then be able to find them.

Yosiaz and Jeff
Thanks so much for your help and suggestions.
As mentioned, the links to (past) e-mail attachments is not mission critical, so, I'm not going to worry about retrieving them. BTW: the attachment feature(?) seems to be working properly on e-mails received since I got this fixed yesterday.
It seems most important, however, that I implement a fail-safe daily back-up procedure; I'd hate to go through this nightmare again. I think I've got one working correctly on my local disk but need to determine if I-Drive is going to work for me in the future (It was NOT handling the SQL files properly - My ignorance.)
BTW: Thanksgiving holidays here in the States - I'm thankful for folks like y'all in this (and other) on-line communities. Stay well, Jim Gunther

I think you can still recover post 10/17 data. Install SQL Express latest on another machine, and restore to that other machine. (there probably is a simpler way on same machine that has your main SQL Server) and start comparing data.
If you can, post the database structure of the db that has the missing data.

I provided several links concerning backups in an earlier response - please view those documents to understand how to backup SQL Server.

If you are running SQL Server Express Edition - then you will need to create batch/powershell scripts to backup the databases and schedule those in Windows Task Scheduler.

If you are running an Edition of SQL Server that includes SQL Server Agent - then you can create a maintenance plan and schedule that within SQL Server.