How would I create a trigger to execute a .exe file on UPDATE or INSERT for a table in Advantage Database Server?
I am new to ADS and I can't really find much documentation on what I want. The support section of their website is a maze.
Did you try the Online help files?
http://devzone.advantagedatabase.com/dz/webhelp/Advantage10.1/index.html
In particular:
http://devzone.advantagedatabase.com/dz/webhelp/Advantage10.1/master_triggers.htm
http://devzone.advantagedatabase.com/dz/webhelp/Advantage10.1/master_trigger_containers.htm
Advantage triggers can be implemented in a variety of containers: SQL scripts, .NET Assemblies, Win32 DLLs, COM objects, or Linux shared objects.
To create such a trigger you can use the Advantage Data Architect (ARC32).
Right click on the table and click "Triggers".
Related
I have a local Sitecore instance where I made changes involving both code and the creation of a new sublayout.
After deploying the code I can see on the new environment the usercontrol (.ascx) file associated to the sublayout, but the corresponding item does not appear and cannot be used.
If I attempt to recreate the usercontrol, it tells me that the file already exists, and due to my lack of experience with the platform I found myself unable to import it.
What would be the optimal way to proceed?
To deploy your new sublayout correctly you should create a Sitecore Package. This is basically a zip file that allows you to move both items and disk files between Sitecore instances in a controlled manner. For basic installs of Sitecore, where you have not added any specialised tools, it is generally the preferred way to move resources between servers.
The "Package Designer Guide" on the Sitecore Developer Network will give you information about how to use the Sitecore UI on your development site to create a package containing both the Item(s) and the file(s) for your sublayout:
http://sdn.sitecore.net/upload/sitecore6/65/package_designer_admin_guide-a4.pdf
Once created, this package can then be imported onto whatever other servers you want to deploy your sublayout to.
-- Edited to add --
Derek Hunziker's answer makes a good point: As well as the basic Sitecore behaviour there are third party tools available which can enhance and extend the deployment experience if you wish. As well as Hedgehog TDS, you might also consider:
The "Sitecore Rocks" extension for Visual Studio allows the creation of packages from within the
Visual Studio UI. This tool is free to use. (https://visualstudiogallery.msdn.microsoft.com/44a26c88-83a7-46f6-903c-5c59bcd3d35b/)
There are also a variety of open source tools - Sitecore Courier is one example: (https://github.com/adoprog/Sitecore-Courier) This is designed to help automate deployment between Sitecore instances.
Both TDS and Courier are most suited to regular deployments, such as those during ongoing development cycles, since they both include automation to help decide what gets deployed. The standard Sitecore UI and the Sitecore Rocks extensions for package creation are better suited to ad-hoc deployments, since you generally pick the things to deploy manually.
A common best practice is to deploy your items along with your code using Team Development for Sitecore. This eliminates the need to create Sitecore packages every time you want to move items between environments, which in turn reduces issues caused by human error. As an added bonus, the items that you own as a developer (such as Templates and SubLayouts) can be checked into source control.
Full disclosure: I work for Hedgehog Development :)
We've decided to create a custom bootstrapper for our deployment solution. We are currently re-writing and re-designing our deployment strategy for all of our products. Sadly, none of us are deployment experts.
Here's what we have so far:
A. The MSI packages will be authored in InstallShield. We will use whatever feature Installshield offers (IIS integration, COM registration, Registry, etc). The dialog's created by InstallShield will not be used (that is what the bootstrapper is for). The MSIs will be installed silently.
B. Whenever we need to write CA's for stuff that InstallShield can't handle, we will be writing them in managed code (C#) using DTF. We will be creating a "Custom Action Framework" that will "standardize" how we use custom actions.
C. We will create a custom bootstrapper (the "setup.exe") in C# to "handle" the installation.
We have decided to go with a multiple MSI approach and use MSI transaction to "chain" the installation from the boostrapper (inspired from Office 2007 installer)
The boostrapper that we are envisioning to create is inspired from Visual Studio's and SQL Server's bootstrapper. The boostrapper will be responsible for the following:
Prerequisite installation: Each application require a pre-requisite. These pre-requisites are listed in an XML file placed on the same folder as the MSI (inspired from Office 2007 installer) along with other metadata. Depending on current state of the system, the boostrapper will decide which pre-requisite to be installed or not.
Feature selection: We are planning to structure the "internal" MSI's feature in such a way that it will not be appropriate to be displayed right away to the end-user. We will have feature labeled as "Core_Files", or "Vista_Only" or "64bit_Only". Depending on the metadata on the XML file (on item 1) and the target system, the bootstrapper will be responsible in "populating" a "feature tree" that the user can customize (also inspired from Office 2007 bootstrapper).
Pre-installation Checks: The bootstrapper will be responsible in checking if the system is ready to receive the installation. For instance, if a machine needs to reboot prior to installation or if the user needs to manually install a service pack, patch or a windows component. Anything that needs to be done that needs user intervention should be displayed here. Think of it as a check list (a listbox) with checks and exes. (Inspired from SQL server's bootstrapper). The "rules" will be written in C#.
Application Configuration: For application that needs to be "configured" prior to installation. These "parameters" (user configuration) will be passed to the respective MSI via MSI Properties.
Actual Installation: The bootstrapper will then perform the installation. Proper "transaction" should be observed when necessary. All "products" that should be grouped together shall be displayed as one product in Add/Remove Programs (by messing with the ARP entries). Also, proper progress shall be reported by each MSI being installed.
-- That's what we have so far.
I think there are a couple of out-of-the-box solutions for creating a custom bootstrapper like dotNetInstaller and BMG. We've look into it but it's not as flexible as we've hoped. There's also BURN but we're not sure if it's ready for primetime.
So here we are... we've decided to create our own custom bootstrapper.
Question:
Are we crazy? Shouldn't we be creating our own bootstrapper? Which ideas listed above are not realistic? Is there a better approach?
Any input regarding our situation will be greatly appreciated. Also, if you have any questions, please don't hesitate to ask.
Frankly, Burn isn't going to be done for at least a year. You already have InstallShield and IMO it has the best off the shelf bootstrapper currently available. I'd scope your requirements back and make it fit the box. Pretty much everything I read from you can be done using InstallShield if you learn to push it to it's limits.
I would go for Burn anyway or some already existing solution.
I'm sure that after some time you'll face new problems that you can't now really imagine.
If you face them, that means that Burn's developers have already faced them and probably got them solved. If not, Burn has a large community that will fix the potential bug faster than you.
Focus on the software you're developing, not on writing installer/bootstrapper.
If I were in your shoes, I would give a burn a try. I'd get me a couple of days and see if it meets my requirements.
I need to create a batch file which will copy web log files from a web server to a local desktop box on daily frequency.
I'm a web developer, but I'd like to take a stab at learning the process for creating a batch file and I think using the windows scheduler should get me where I need to go.
In any case, I'm just looking for a jumping off point.
I understand the premise behind a batch file (echo to print info, commands to cause actions such as mkdir or move, etc), but some straight forward tutorials would be great.
Or even a reference guide such as devguru.com or 4guysfromrolla.com would be helpful.
Thanks,
Creating a batch file is relatively straightforward.
Just type out the commands you want as you would in the command shell, and save the file with a .bat extension.
There's a simple example here that you may find useful. Note, you can use any editor to create your batch file, as long as it saves in a text format.
Depending on which version of Windows you're using, the process to create a scheduled task is slightly different:
Windows XP
Windows Vista
Edit: A little followup on misteraiden's answer.
Essentially, what you're looking for is scripting functionality. There are a variety of tools available. A batch file is the simplest form of scripting that Windows supports. You could, for example, write scripts in PowerShell or Python. Both are more powerful and flexible scripting languages. Depending on what the requirements are for your script, and what you feel like learning, they may be more appropriate.
However, If all you want to do is a copy, the simplest, easiest place to start is a batch file.
This is a little left-of-field, but using an XML build interpreter such as NAnt could come in handy here. Probably over-kill for what you are trying to do, but if you learn it now, you'll be able to apply it's uses in many different places.
You could use Windows Scheduler to trigger the build, which would then complete various operations such as deleting, copying, logging on to network shares.
However, perhaps to learn this you would probably need to learn more about the command line and command line programming.
Either way, I recommend you check out some of the NAnt examples that deal with copying and other basics etc..
I found one of the best references other than the Microsoft website that was mentioned in an earlier is: http://www.robvanderwoude.com/batchfiles.php I have been using this for many of the issues I have had and have been using it to learn more. I think since you have the premise of how batch files work, this will work out will for you.
Currently I go into phpMyAdmin, export my database as a text file and then save it with the application files before I commit things to svn (or git). Then of course, I've got to import it to production.
Is there a better way?
Depends on the language you use, RoR has it built in. Currently for a project I'm doing in ASP.net MVC I have 2 files in the project in a folder: database. One file contains the structure of the database and one file some dummy variables for testing. I must say it is a cumbersome way of sharing your database since when you update something you have to let the others know they have to rerun the (updated) sql structure script.
The structure script deletes tables if the exist and readds them + adds new tables.
Could not find a better way like db::migrate of Ruby on Rails.
If you don't have something like rails migrate, are in java environment or anything else, check out liquibase. It's pretty cool if you need that much flexibility. We just track .sql files which setup the entire database.
Generally, I would create a script that is able to generate the database (i.e., all the tables, users, views, indexes, etc) and another script that populates the DB with data. Then, use DBDeploy (similar to RoRs migrations) to handle all DB modifications. Then I would create build targets for all these script in Ant, NAnt, Buildr, etc. This way everything is versioned and in text files so it works with any SCM.
If you're looking for migrations similar to db:migrate in Rails, but you're not in rails, there are other options. There's migrate4j which is similar to db:migrate, but written in/for Java. There's also liquibase, which is very flexible and (AFAIK) language independent, but does make you write everything in XML (which is kind of the opposite of "the Rails way").
If you look at Apache ODE, they have a h2.rake task for Buildr that builds a database for testing automatically.
Is it possible to use PowerShell to script out SQL Server Reporting Services rdl files in SQL Server 2008? If so, can someone provide a code example of doing this? This would be a useful replacement for using a 3rd party tool to script out RDL files created by business users outside of my Business Intelligence department.
CLARIFICATION OF THE TERM "SCRIPT OUT"
By "script out", I mean I would like to automatically generate the underlying RDL file for each report on the server. For instance, when you code report in BIDS, you are generating a RDL file. When you deploy the file to the server, the file is somehow imported into the SQL Server ReportServer database and it is no longer a separate physical RDL file. I would like to extract all the reports from the server in a RDL file format.
I've used the RSScripter tool to extract the reports as RDL files, so I know it is possible using tools other than PowerShell. I would specifically like to know if it is possible to do it using PowerShell and, if so, get a sample of the code to do it.
CLARIFICATION ON WHY I WANT TO GENERATE RDL VERSIONS OF REPORTS
Why is it important to "script out" the reports to RDL files? I would like to check-in the RDL files to my source control system once a night to keep track of all reports created by users outside of my Business Intelligence department. I already keep track of all reports generated by my department since we develop our reports in BIDS, but I can't keep track of versioning history on reports built in the online Report Builder tool.
CLARIFICATION ON WHY POWERSHELL AND NOT SOMETHING ELSE
Curiosity. I have a problem that I know can be solved by one of two methods (API or RSSCripter) and I would like to know if it can be solved by a 3rd method.
Opportunity to expand my problem solving toolbet via PowerShell. Using PowerShell to solve this problem may provide the foundation for learning how to use PowerShell to solve other problems that I haven't tried to solve yet.
PowerShell is easier to understand for my team and me. In general, my team members and I can understand PowerShell code more easily than .NET code. Although I know this problem can be solved with some .NET code using the API (that's how RSScripter works after all), I feel it will be easier for us to code and maintain a PowerShell script. I also realize a PowerShell script will probably use .NET code, but I'm hoping PowerShell will already be able to treat the reports like objects in some way so I won't have to use the Reporting Services API to extract the files.
RSScripter doesn't support 2008 yet. In the past, I've used RSScript to script out reports. Unfortunately, it doesn't appear to support 2008 yet. This means I have to write code against the API right now since that's the only way I present know how to extract the files in an automated unattended manner.
a little late, but here you go
This PowerShell script :
1. Connects to your report server
2. Creates the same folder structure you have in your Report Server
3. Download all the SSRS Report Definition (RDL) files into their respective folders
https://sqlbelle.wordpress.com/2011/03/28/how-to-download-all-your-ssrs-report-definitions-rdl-files-using-powershell/
PowerShell doesn't provide any native, PowerShell-esque functionality for this, no. You can do this in PowerShell (as noted in the previous answer) only because PowerShell can access the underlying Framework classes. As you noted in your comment to the previous answer, it's no different from using the API in C# or VB.
The SQL Server team has not yet provided much in the way of PowerShell-specific stuff. They're primarily relying on .NET and T-SQL as "scripting languages."
I just realized the Content column in the ReportServer.dbo.Catalog contains the definition in an Image format. I wrote the following code to convert it to readable text:
SELECT CONVERT(VARCHAR(MAX), CONVERT(NVARCHAR(MAX), CONVERT(XML, CONVERT(VARBINARY(MAX), Content))))
FROM [ReportServer].[dbo].[Catalog]
WHERE Type = 2
With the above code, I can now automate writing the results to a flat file and then import the file into my version control system.
Anything that supports .Net can do this. See this Stackoverflow posting for some links to the API docs. The process is actually fairly straightforward - the API has a call to upload or download the .rdl file.
Report models are a bit more fiddly. You have to get the dependent reports (again an API call) and re-connect the data source if you upload a new report model. Again, not terribly strenuous.
Powershell should do this fine. I've variously done this with IronPython and C#. There's a also a tool called rs.exe that takes a vb.net script, tops and tails it with some includes and compiles and runs it behind the scenes.