FileTable External Process Like Zip using T-SQL - sql-server

Has anyone ever tried to use tsql to launch external processes against files in a FileTable? I have not been able to find anything so if may not be possible.
In particular I am looking into PGP and ZIP operations. My backup plan is to use C# in combination with queries against the filetable.
I am curious to know if it can be done with T-SQL instead. I have looked at xpcmdshell to launch a process but many people recommend against this.
Thoughts and ideas are much appreciated.

Can set folder to compressed (or on EFS)?
See http://blog.brucejackson.info/2013/04/sql-file-table-step-by-step.html

Related

Including scripts in QueryBank / Saved Export queries?

Can I incorporate scripts setting variables and while loops, etc. in the "QB Query" of the Query Bank?
I have a SQL Server script that works perfectly in my local dev DB but it doesnt play nice with Volusion.
I don't know if I should spend more time figuring it out or just stop because it isn't even possible.
You can't do it in the Custom Queries / Query Bank area. I believe their system will stop executing the script when it encounters certain keywords or punctuation. A work around is to create a .sql file that contains your script and place it in your vspfiles/schema/Generic folder. You'll also need an .xsd file with the same name. The contents of the xsd file aren't very important - you can reuse the contents from an existing one (search their support pages for Developer Resources to find examples). Once the sql and xsd files are in place, you can execute the SQL in the .sql file by using the URL/API method, like this...
http://www.MYWEBSITE.com/net/WebService.aspx?Login=USER#MYWEBSITE.com&EncryptedPassword=XXXXXXXXXXXXXXXXX&EDI_Name=Generic\FILENAME (<-- minus the .sql extension)
you'll need to replace several things above of course. But this works well for us. One thing to note, if you automate the creation and execution of these files, it's slow/inefficient on their system and could slow your site down, depending on how often you do it.

Export Databases of DOS Clipper Application

Our current system database system is a clipper DOS application. The database inside its folder is fragmented/divided into many parts. I want to decrypt the database so that I will have only one database in all and avoid reshuffling of data. I'll attached the file folder Screenshot.. the database is on .DBF format
VScreenshot of files
Often you can decompile the CLIPPER exe file to source code and work from the .prg I've done it many times. The program to use is called WALKYRIE.
In Clipper and Fox Pro for DOS .dbf file is a simple table file.
If You want to use as data base with many tables in one unit.
You can import these tables in MS SQL data base and/or part of a MS Access database.
I see that you got several answers. Most are partially right. Let's address these one at a time:
All those files essentially comprise the "database" for the application you're using. They could be used by other applications as well. Besides having a lot of files, what is the problem you're trying to solve?
People mentioned indexes. You can generally ignore these. There are there primarily to make access to the data files faster. Any properly written clipper application will recreate these if they're missing or corrupted. You could test this by renaming one, running the app, and seeing what happens. If it doesn't recreate it you can name it back. Not replacing missing index files would be unusual behavior.
The DBF file format is binary, but barely. Most of what's in a DBF is text and is readable with an editor. But there's no reason to do so - I'm sure there are several free DBF utilities out there to to read DBF files. Getting the structure of the files could be very helpful.
Getting the data out of the files would also be fairly simple with a utility. If you look up the DBF format you could even write one fairly easily in Clipper, any other language that uses DBF files, or in something like Python. Any language that can open and write files, really. It's not hard - any competent developer could do this in a matter of hours. Must less if you're using Clipper or another language that natively reads DBX files.
Most people create dBase/Clipper programs with relational data, like SQL Server. Where SQL Server has tables that relate to each other dBase/Clipper has a file for each "table." This isn't a requirement, but it was almost certainly done this way.
Given that, if you get the table structures through a utility or by reading the headers in an editor (don't save them from an editor!) you could quite likely recreate the database schema (i.e. the map of the data). Once you have that it's fairly trivial to get the data into another type of database (SQL Sever, Access, or whatever you like to use.) If non of the files are too large it's conceivable to put all the files into Excel sheets. It really depends on what you want to do with it.
As others have said, you may be able to get the code by Valkyrie. Some people have used it very successfully. I don't know where you get it and I've never used it. Why do you not have the code? If this is a commercial application you likely should not have it. If it's a custom app who ever wrote it or paid to have it written should have the code.
Again, it's not clear to me what problem you're trying to solve. But there are many options for doing something with those DBF files. Fortunately they are one of the easier to read data formats you could be working with.
Let me know if you have any questions. Apologies for the typos that are no doubt scattered throughout this reply.
You sort of can get an idea of how they relate to each other by opening the index files they use (.NTX files). If you have the DBU utility (executable) around, you can open the DBF and load the index (NTX). LibreOffice Calc is also able to open DBFs (haven't tested .NTX).
If you open the .NTX on a text editor you will see the indexes in the beginning.
I open with Access, but I can save the data using a PrintFill Program.

How to store the result of an SQL query to an XML file in a specific folder without using cmdshel

I have an SQL Server query and I am using FOR XML PATH to generate the result as XML. I am trying to save the file result.xml to a particular folder of my computer but I do not want to use the "save as" link of SQL Server to do it, because I need to automate my process.
Unfortunately, I cannot use xp_cmdshell solution provided here because I do not have the permissions to do it. In fact I get an error
The EXECUTE permission was denied on the object 'xp_cmdshell', database 'mssqlsystemresource', schema 'sys'
each time I try to execute it.
May anyone help me with that? It would be highly appreciated!
Good day,
like always there are lot of solutions which depend on your knowledge and resources. I will try too give you some ideas here and probably others will be able to add more
Using SQLCLR you can simply create a file and save it (this will require using PERMISSION_SETUNSAFE)
Using Python (basically same as SQLCLR we can do everything with Python including external tasks).
You mentioned that you do not want to use xp_cmdshell at first but after the short discussion I understand that you simply do not succeed to use it, but this is your preferred option. Check this thread on the same topic. You should find the solution there on how to configure the permissions.
Using sp_send_dbmail you can send the result of the query to email. Not like other options this is usually open in most servers. The idea is to send simple email, and using Google Apps you can read the content of the email and create file. You can use for example the methods: GmailApp.getInboxThreads, getMessages(), getRawContent()... and in order to write the file in your Google drive you can use DriveApp.createFile
Using SSIS
Following your advice I took the time to learn how to use C# in order to solve my problem and now it works perfectly! I created a short script that executes my sql query using for xml path and then managed to save the resulting XML file in a specific repertory. Thank you again for the support. So my process is now fully automated. Always nice to learn more!

Granting access to master.sys.xp_dirtree SQL

There may be an answer to this somewhere else on here, but I can't find it.
My organization uses a EHR called TIER that has a SQL back-end. One of the features of the EHR is that you can "scan" a document to a folder on the network with the unique ID of a row in a table on the server. Then from the EHR, you can open a record from the table and then it links to the documents in the folder with the same Unique ID.
An example may be helpful - In the EHR I create a document (a row in the ScannedFormTable) with unique ID of 100. I then "scan" (basically attaching or copying) a pdf or other document into a folder on the network (say D:\ScannedDocuments) with the name of 100, so abc.pdf is now in D:\ScannedDocuments\100. Then from the document in the EHR, I can open the pdf. However, without opening the document to check I can't see if there is any file in the ...\100 folder.
Through some googling, I found that using master.sys.xp_dirtree (and "Undocumented" procedure I think) I can have the EHR "see" the name of files "attached" to the documents. The issue is that I can run this stored procedure from SSMS, but can't from the EHR itself. I have tried to figure out a way to grant security permission for the user in the EHR to run the procedure vs running the script in the background on the server at regular intervals.
Any insights would be greatly appreciated. As you may have noticed from the number of " used, I am a self taught SQL user who is better at googling than actually understanding the intricacies of the language.
I found that using master.sys.xp_dirtree (and "Undocumented" procedure I think) I can have the EHR "see" the name of files "attached" to the documents.
I think you are confusing different things. Yes, YOU can (and tsql can) use that undocumented and unsupported procedure. However, your "EHR" is a system designed to provide specific functionality. It isn't clear what you are trying to accomplish, but to "get" your system to do something obviously depends on your system, its features, and what you are actually trying to accomplish.
I'll add that tsql is not designed to access the filesystem natively - hence the use of undocumented extended procedures. If you are simply trying to verify or traverse this ScannedFormtable table and verify that there is some sort of file in the appropriate location, you might find this task easier to implement in a typical programming language.
If you want better suggestions, it would help to discuss your goal. And consider carefully what you are trying to do, since it is quite easy to create a security hole by altering permissions.

Best tool to document T-SQL *source* files?

At work, the database is not documented at all. Furthermore, the stored procedures, functions and views are all encrypted, this rules out a lot of tools that document these objects for you. All I have are the plain .SQL files that generate the database, schemas, tables, functions and all.
I'd like to know, is there a tool that can read these files and generate a Doxygen-like documentation? Preferably open-source or freeware.
I found IzzySoft's HyperSQL and SourceForge's project PLDoc do something very close to what I'd need, though both seem to be very PL/SQL specific. I want something that reads SQL source files (that understands T-SQL's idiosyncracies), parses them, and gets me:
List of SPs, UDFs, etc. defined within each file
List of objects (both tables/views and procs/functions) each object depends on (directly and, if possible, also indirectly)
Calling and dependencies graphs (i.e. what calls what and is called by what)
If possible, when an SP uses a table/view, how's it using it (INSERT/DELETE/UPDATE/SELECT/mix???)
I've already developped a tiny Perl script that minimally parses these files attempting to get first point - but then it's just a hack and lacks a lot of polish. I'm sure there must be a tool out there which does the job, I want to believe I won't have to code it myself.
Thanks in advance,
Joe
We use Red Gate SQL Doc to generate ours.
However, it works from a database not files: it's easier to read everything from system tables (permission, dependecies, datatypes etc) than parse scripts. Parsing scripts is what the DB engine does...
Can you not generate an empty DB from the source files (remove WITH ENCRYPTION) and generate from that?
Or decrypt if you have sa rights?

Resources