Tag Archive: Advent


Using Visual Studio Code to Modify Advent Replang Reports in Axys and APX

Filed under: APX, Axys, Portfolio Management Systems — Leave a comment
September 9, 2024

Image created using AI query for Python code to create word art with Replang keywords.

The State of Reporting Development for Axys and APX Users

Advent users continue to benefit from many different report development options. There is a tantalizing and sometimes dizzying array of reporting options both within Advent’s architecture and provided by third-party solution providers, products and platforms.  In most cases, leveraging the most enticing options takes a commitment of time, money and patience.

At the top, management may envision staff using a single transformative technology that unifies all the data and makes it easier to push, pull or outright access data from portfolio accounting and ancillary systems. However, the truth, at least where Advent is concerned, is that the most effective way of making all those wonderful connections between applications and other data sources is a blended approach using the most effective method for various data elements.  A cohesive strategy and well-organized approach to data gathering and sharing should be implemented, but it is not critical or realistic that all data elements be delivered via one approach or method.

APX users have the ability to tap data from APX’s underlying SQL Server database using a growing combination of data integration options within the framework of APX.  These options include Stored Accounting Functions, Public Views, SSRS and REST API – as well as any other reporting tools and systems that can make use of that infrastructure.  APX users have a lot of capabilities baked into the platform that Axys users don’t have, but from what I typically see out in the wild, most firms using APX aren’t leveraging those features as well as they could.

Evolving Report Development Options for Axys and APX Users

Axys, APX and other portfolio accounting system users, who have taken the time to use ETL tools, like xPort, to populate their own data warehouses, will have similar data schemas focused on the most critical data (e.g., clients, agreements, revenue, portfolios, transactions, performance, holdings, etc.) to their respective businesses.  Depending on firm size and budget constraints, these users may benefit from tapping that data with a visual analytics platform like Pyramid Analytics, Microsoft Fabric or Tableau.

I am excited about the latest emerging tech and currently working with what I see as some of the best platforms and tech available.  Newer tech isn’t going away, but for someone with their feet firmly planted on the ground who needs to generate a relatively simple report today, it probably makes sense to hit the snooze bar momentarily and attempt to do what needs to be done now.  Though it may appear outdated by comparison, Axys and APX users can also create reports using Report Writer Pro or via updates to Replang source code directly.

While advanced reporting tools can be extremely powerful and, in fact, instrumental for some types of reporting requirements, I am a fan of Occam and his razor. In many cases, there is just no need to complicate reporting any more than is useful to accomplish the end goal. Replang, which was established in Advent Software’s infancy, is still very much part of the reporting architecture of Axys and APX and will likely remain part of it forever.

Like many Advent users out there, I have used Notepad and/or Notepad++ to modify Advent Axys, APX and Report Writer Pro reports. I was modifying these files via the MS-DOS Edit command way back when they were part of The Professional Portfolio. Any of the tools are sufficient, but plain old Notepad and Edit don’t even display line numbers; Notepad++ is a step in the right direction, as it provides line numbers and the ability to use plug-ins, but neither option could be considered a modern tool for source code modifications.

Visual Studio Code

That’s where Visual Studio Code (VSCode) comes in. VSCode, which is perhaps one of the most popular and versatile utilities for source code updates, offers support for many of today’s most popular languages and a few of the older ones as well. When I first started using VSCode, I did a quick search for a Replang extension. Unfortunately, Replang wasn’t one of the supported programming languages, but VSCode does allow developers to build extensions, which are similar to plug-ins in Notepad++.

Prior to creating the extension, I also tried a number of the available supported languages in VSCode to see if anything came close. Some of the best candidates helped a little, but I was disappointed with the results. Out of the gate, VSCode provides line numbering and many other useful features. Frankly, the only reason to ever use Notepad again is because it is always there and it is simple to use.

In order to provide language support for Replang in VSCode, I needed to create an extension with knowledge of Replang’s keywords. Replang for Axys has roughly a hundred keywords, and the most current versions of APX add another hundred-plus keywords. Building a truly robust extension for Replang would mean spending more time than I put into it on the day I created it. Ideally, you could provide keyword-specific information with examples that would appear when you hover over a keyword. Eventually, I may build that into the extension, but the most critical feature in my mind is to provide contrast between keywords, comments and dialog to highlight the syntax and make it easier to read.


Example: Modifying Replang code with Visual Studio Code using the Replanguist extension.

If you routinely modify Advent Reports and are looking for an improved tool to do so, you may want to check out the Replanguist extension I built and published to facilitate Replang edits. You should be able to find it in the list of available VSCode extensions from Microsoft.

As always, if you have questions or suggestions, please feel free to reach out and connect with me.

Kevin Shea Impact 2010

About the Author: Kevin Shea is the Founder and Principal Consultant of Quartare; Quartare provides a wide variety of technology solutions to investment advisors nationwide.

For details, please visit Quartare.com, contact Kevin Shea via phone at 617-720-3400 x202 or e-mail at kshea@quartare.com.

Tags: , , , , ,
Comment

Advent’s Worst Enemy?

Filed under: APX, Automation, Axys, Best Practices, Business Continuity, Portfolio Management Systems, SQL Server — Leave a comment
December 21, 2023

I have said it before, and I’ll say it again: if Advent does well, it follows that someone like me should do well, too.  I profit directly from Advent customers when they hire me, and indirectly when companies that provide services to Advent customers hire me.  That said, there is a certain amount of Advent’s dysfunction that helps my business.  In short, I offer what Advent cannot and/or does not want to provide to their customers, and many of my customers hire me specifically because I do not work for Advent.

 

Steeplechase race in 1912, Celtic Park, N.Y., through water

On the other hand, there is a limit to what is reasonable.  If Advent proverbially lights their hair on fire and jumps off a tall building, that is not good for me or my business. With thirty-five years of experience dealing with Advent, acting as an advocate to clients, I have seen some absurd things and have a high tolerance for some of it, but even I will occasionally find myself flummoxed.  It pains me to say so, since I really want Advent to succeed… at least enough that they aren’t losing business to competitors without good reason.  That is bad for their business and mine.

Advent Options

If you are to believe the natural progression of things as they are presented to the masses, it follows that some Axys customers who are frustrated by its limitations can be better served by Black Diamond or APX.  From what I have seen personally, Advent hasn’t had great success moving Axys customers to Black Diamond.  I have seen a few good Axys clients go Orion and Tamarac, but I have yet to see one of my clients go to Black Diamond successfully. This is not meant as a criticism of Black Diamond – it’s just an observation that my typical clients haven’t found the complete solution they are looking for in Black Diamond.

For those firms where Axys is no longer the answer and Black Diamond cannot meet their expectations, APX may offer a viable upgrade path.  Aside from its cost, APX has always been a relatively easy upgrade choice for Axys users to make because it is an Advent option that supports the legacy of Axys, which includes knowledge of portfolio management and performance fundamentals, transactions, processes, reporting, and scripts.  That means that when those customers move to APX, much of the reporting, infrastructure and established workflows can remain the same.

In short, APX offers everything that Axys does, plus the benefits of an Enterprise/SQL server platform.  The incremental learning required for operations staff to go from Axys to APX is very manageable, and things pretty much work like they did in Axys.

Among APX offerings, I know of at least five possible permutations:

  1. APX Self-Hosted on Premise
  2. APX Self-Hosted in the Cloud by a Third Party
  3. APX Dedicated with AOS
  4. APX Dedicated without AOS
  5. APX Multi-Tenant (hosted by Advent)

I have listed these APX environment options in order of my personal preference, based on specific experience with all of the options and the ease with which one can effectively manage, integrate, automate, and enhance systems. From my perspective, the first two options clearly give you the greatest degree of control and autonomy over your own systems. Choosing one of the other three options puts you in a place where Advent is enforcing various controls over your system – good and bad. Firms that have always had complete control over their systems and want to continue to do so should bristle at the very idea of this.

Advent’s Dedicated Hosting Service for APX Users

One that is used to hosting their own APX system on premise might think that hosting via Advent’s dedicated environment would be nothing but a boon, but reality quickly shatters that dream for savvy, hands-on APX users. Advent’s value add here is clearly AOS, but if that is the case, why would they ever sell someone dedicated hosting without the AOS service?  When they do that, the Dedicated Hosting service provided is arguably no better than what a third-party vendor can deliver.  Oh, wait, that’s not true.  It is potentially worse, because the system will be locked down in such a way that you won’t be able to do the things you would be able to do if your APX hosted environment was provided by a third-party resource that needed to make sure you were satisfied with their service.

This is because, without an AOS resource, some things that a firm would want to do to automate and enhance their systems simply cannot be done because they fall under the responsibility of the AOS silo.  You can call Advent support all you want, but they cannot resolve your problem, because only AOS can do these things.

Want to schedule a process to run at a certain time?  You can’t do that.  Do you want to install a third-party product?  You can’t do that.  Do you want to log into the server directly?  You can’t do that either. All of these things are only possible with the cooperation of an assigned AOS resource.   And even if you have an AOS resource, you still cannot do those things, but instead must ask your AOS resource. 

A fitting analogy for comparing the work required in their locked-down environment to what one might otherwise do in a self-hosted environment could be comparing the 100-yard dash to steeplechase.  As a result, the automation that you may create is more likely to resemble a Rube Goldberg machine than a typical streamlined process due to Advent’s forced assistance and rules regarding what can and cannot be done. 

 

Unfortunately, as you invite a higher degree of involvement from Advent vis-à-vis Advent’s dedicated (a.k.a. “managed”) hosting model, you lose control of the systems you are entrusted to manage and improve unless you had the foresight to have Advent agree upfront to the access rights required or are willing to spend countless hours dickering with Advent about the rights, which may ultimately end in frustration anyway.  This comment is not based on my direct experience with these systems alone, but also what I have heard amongst my peers.

Advent basically has the keys to the kingdom in this scenario, and the users are at the mercy of Advent. It’s almost plausible that they cannot allow you access to certain areas of the system that you usually have, but at the end of the day, when you cannot easily perform work that you were able to do in the past when you self-hosted APX, it feels much more like a ruse intended to ensure that Advent gets not just what clients have agreed to pay them, but any other work you might want to perform in the environment related to automation.

However, the problem is that they cannot necessarily perform the same work of a contractor with specific experience Advent may lack.  From my perspective, Advent’s focus in their Dedicated Hosting seems to be maintaining the status quo, not constantly striving to build a better mousetrap to service your business processes.  That is the directive I am looking for from my clients.

Anyone that can’t envision how Advent could consume their money, time, and resources while providing this service to them may lack experience working with Advent, or the imagination necessary to take their own client experiences with Advent and extrapolate the possibilities once Advent has a greater degree of control over their systems.  The frustration this arrangement creates can be amplified if the firms facing this entanglement are committed to long-term, bajillion-dollar contracts.  These large, multi-year contracts could be part of the reason Advent feels comfortable repeatedly saying the one word my clients never want to hear—no.

Over the years, Tamarac, Orion, Addepar and Ridgeline have all made inroads to capture market share from what was once predominantly Advent’s business to keep or lose, and they will continue to do so until Advent makes improving its rapport with clients a priority.  You may have already guessed, but Advent’s worst enemy and biggest threat to the future of their business may be Advent’s hubris, and winning the WatersTechnology Buy-Side technology award for the Best Portfolio Accounting Provider two years in a row is unlikely to change that.  Even so, if you have deep pockets and are truly ready to hand the reins over to Advent, you may be happy with the results.

 

Kevin Shea Impact 2010

About the Author: Kevin Shea is the Founder and Principal Consultant of Quartare; Quartare provides a wide variety of technology solutions to investment advisors nationwide.

For details, please visit Quartare.com, contact Kevin Shea via phone at 617-720-3400 x202 or e-mail at kshea@quartare.com.

Tags: , , , ,
Comment

Schwab Changes Continue to Impact Some Advisor Workflows

Filed under: APX, Automation, Axys, Data Conversion, Portfolio Management Systems, Sunset — Leave a comment
August 30, 2023

After Labor Day, summer is effectively over for investment professionals. Most executives and senior staff of financial services firms return to the office from vacations recharged and ready to go. Next week, they may need to tap that extra energy if they have to cope with the conversion of TD Ameritrade accounts to Schwab accounts. Schwab Advisor Center will be temporarily unavailable from September 2nd at 2am ET through September 5th at 5am ET while they complete the integration between Schwab and TD Ameritrade.

Earlier this summer, Schwab stopped generating transactions and positions, as well as other files that were scheduled to be sunset. Schwab gave customers over a year of warning that this change was coming. However, I cannot help wondering how difficult it would have been to keep generating those files, or better yet, refer those customers to me directly for assistance. Schwab wasn’t interested in doing either. As a result, customers that were impacted may still need to update or change systems that were dependent on those data feeds for daily workflows in order to process the transactions and positions data received after 07/11/23.

 

 

Creating Price Files Compatible with Advent Products

When I blogged about Schwab ending support for legacy price and transaction files around this same time last year, I didn’t know if I would be willing to create a translation utility to take Schwab CRS transaction files and convert them to Advent’s CS transaction files.  Writing the utility for prices was relatively simple by comparison.  I collected a one-time service fee from customers, and in turn facilitated their ability to keep their pricing workflow intact through the use of that utility. The utility processes CRS security files (CRSyyyymmdd.SEC) to create CS price files (CSmmddyy.PRI). Once the CS files have been created, they show up in Dataport as they always have in the past.

I felt good about the fact that I was able to help those customers in very tangible way with little effort on my part.  If you haven’t read the blog, you can find it here.  In short, the blog details the issue at the time, some possible solutions, and warns users that the conversion of transactions will be a larger and more costly issue to address.  At that time, I was not committed to writing a transaction conversion utility.

I have included a rudimentary VB code sample below to translate Schwab’s newer CRS SEC file to the legacy CS PRI Advent format required by some users:

 

VB 
Sub CreatePriceFile(Folder As String, FileDate As Date)

'This subroutine converts Schwab CRS files to Advent's
'naming convention (CSmmddyy.PRI) and file format to be
'compatible with Axys and Dataport.  This is the same format
'that was provided via the Schwab Point-to-Point interface.

'Once this routine has been run on a CRSyyyymmdd.SEC file, 
'Dataport will recognize and be able to convert these files
'as it did prior to Schwab turning off the feed. 

' written in VBA by Kevin Shea (aka AdventGuru) & updated 08/30/2023

' Disclaimer: This routine works fine for the specific instance it was
' created for, but could need additional modifications for different
' circumstances.

On Error GoTo CPErrorHandler

dim Fields() as string
Dim Spaces, OutfileFH, IngestFH As Integer
Dim Record, Price, RawPrice, CUSIP, SType, Ticker, AssetIs As String
Dim SourceFilename, DestinationFilename As String

SourceFilename = "CRS" + Format(FileDate, "YYYYMMDD") + ".SEC"
DestinationFilename = "CS" + Format(FileDate, "MMDDYY") + ".PRI"

OutfileFH = FreeFile
Open Folder + DestinationFilename For Output As #OutfileFH

IngestFH = FreeFile
Open Folder + SourceFilename For Input As #IngestFH

Do While Not EOF(IngestFH)

  Line Input #IngestFH, Record

  If Left$(Record, 2) = "D1" Then
  'Only process the detail records.
  'Ignore header "H1" and summary "T1" records.
 
    Fields = Split(Record, "|")
    'This is a great VB command that splits the contents of the record and puts
    'it into an array.  For example, fields(0) contains the value of first field
    'in the record, fields(1) contains the value of the second field and so on.
     
    'Assign the fields to named variables we need to build the price file, which
    'makes the code easier to read later.

    Ticker = Trim$(Fields(9))
    AssetIs = Trim$(Fields(6))
    CUSIP = Trim$(Fields(11))
    SType = Trim(Fields(8))
    Spaces = 9 - (Len(SType) + Len(Ticker))

    'Remove the leading zeros from the price field value.
    'May not be absolutely necessary, but we do it anyway.
    'You might be tempted to use the replace statement here
    'instead, but that would have unattended consequences.
    'We are only removing the leading zeros.

    For x = 2 To Len(Fields(34))
      If Mid$(Fields(34), x, 1) <> "0" Then
        Price = Right$(Fields(34), Len(Fields(34)) - (x - 1))
        Exit For
      End If
    Next x
  
    'Ignore securities if they are derivatives.
    'If a ticker exists use that.
    'Otherwise, assume we need to use the CUSIP.

    If AssetIs <> "DERV" Then
      If Trim$(Ticker) = "" Then
        Spaces = 12 - (Len(SType) + Len(CUSIP))
        Print #OutfileFH, SType + Left$(CUSIP, 8) + Space(Spaces) + Price
      Else
        Spaces = 11 - (Len(SType) + Len(Ticker))
        Print #OutfileFH, SType + Trim$(Ticker) + Space(Spaces) + Price
      End If
    End If
  
  End If
Loop

Close #IngestFH
Close #OutfileFH

Debug.Print "Price file " + DestinationFilename + " built from " + SourceFilename + "."
Log ("Price file " + DestinationFilename + " built from " + SourceFilename + ".")

Exit Sub

CPErrorHandler:

'Nothing happens here, but some logging.
Log "An error occurred in the sub (CreatePriceFile)"

End Sub

Sub Log(LogMessage As String)

Dim LF As Integer
LF = FreeFile
Open Application.ActiveWorkbook.Path + "\SPTP_Price_File_Translator_Log_" + Format(Date$, "MMDDYYYY") + ".txt" For Append As #LF
Print #LF, Format(Date$, "MM/DD/YYYY") + " " + Format(Time$, "HH:MM:SS") + " " + LogMessage

Close #LF

End Sub

 

CRS Transaction File Translation

As the July 2023 deadline imposed by Schwab approached, some of the users I assisted with the CRS Price File Translator reached out to me to see if I was going to create a tool to address it. Eventually, I agreed to do it in July.  Working from samples of the first customer’s historic CS transaction files (CSmmddyy.TRN) and the newer Schwab CRS transaction files (CRSyyyyddmm.TRN), I was able to map over fifty different types of transactions and build a tool to convert the CRS files provided by Schwab into the format compatible with Advent and Dataport. 

There is some redundancy in Schwab’s transaction mappings.  Schwab seems to create a distinct transaction code and mapping for more transactions than necessary. For example, there are at least six different types of dividend mappings and similarly at least three different ways that they categorize a check that was written.  My goal in writing the translator was to preserve the information and create a file nearly identical to what Schwab has been generating for several years.

 

The CRS Position File

When I agreed to create the conversion utility for transaction files, I failed to realize that I would also have convert the position files so that users can continue to utilize the Schwab Reconciliation Report in Advent. So I created the position translator gratis.  While analyzing the file I found that Schwab has two different record types encoded in their CRS RPS files. The first block of records appears to be non-cash assets.  The second block of records are cash-only. Those records start with “D1” and “D2” respectively.

Those familiar with Schwab’s cash types may already know that they have nearly twenty different types of “cash” that get baked into the position files.  The CRS RPS file has the asset value for these various cash types for each account stored in a single record, which means that we needed to read the cash records from the CRS file and create multiple records in the CS file.  Conversely, the non-cash records are translated into a single record in the CS file we created.

The tool has been used to convert the transactions and positions from 07/12/23 forward.  It is now being used in day-to-day operations at that firm.  There have been a small number of mapping issues we needed to fix, but overall, the CRS Translator – which now creates CS PRI, TRN and RPS files – is working well.  In the past week, I signed up a few additional customers for the service and expect to hear from more potential customers due to the upcoming Schwab/TD Ameritrade (TDA) work scheduled for Labor Day weekend.

 

What is going to happen to AD files currently generated by TD Ameritrade?

Apparently, Schwab will stop providing similarly constructed legacy files to the TDA advisors.  My understanding is that those Schwab customers will receive CRS files populated with their data for the first time on 09/05/23.  They have been receiving empty files with headers alone to date. If their workflows have any dependencies on the old file formats, they will need to convert those files ASAP or make other changes to their systems to implement new workflows, such as ACD, so they can continue to download prices and transactions and reconcile positions in a timely manner.

 

About the Author: Kevin Shea is the Founder and Principal Consultant of Quartare; Quartare provides a wide variety of technology solutions to investment advisors nationwide.

For details, please visit Quartare.com, contact Kevin Shea via phone at 617-720-3400 x202 or e-mail at kshea@quartare.com.

 

Tags: , , , , , , , , , , , , , , , ,
Comment

Bringing Axys Back to Life

Filed under: Axys, Best Practices, Business Continuity, Installation, Portfolio Management Systems — Leave a comment
November 29, 2022

With my long-standing history as a seasoned and impartial technology consultant catering to the wide-ranging needs of Advent users, it should come as no surprise that companies that have moved away from Advent call me to assist them if they have Advent specific needs after their agreements with Advent have lapsed.  In those specific cases, I suspect my independence from Advent is one of the most appealing features of my service, but many Advent users that have ongoing agreements with Advent also retain me to provide a level of service that Advent seems unwilling or unable to provide.

One of the things I get regular calls about is getting Axys running again.  These calls occur either when firms upgrade their servers or when firms that have moved on to competing Portfolio Management Systems dust off their old Axys files with hopes of tapping into Axys again.  My experience consulting to financial services firms using Advent Software for thirty-plus years facilitates my ability to resolve issues like these easily. 

Many of those calls I get start with the caller telling me, “We reinstalled Axys on the server and it isn’t working.”  And inevitably, this tells me more about the underlying issue than the caller ever could.  You certainly can reinstall Axys, but you probably don’t need to because Axys on the server is just a bunch of files that you access from another PC.  The most important thing to keep Axys working properly aside from the proper installation being done (at some point in the past) is making sure that users have all necessary rights to the shared folders.

This article is focused on explaining what the requirements are to empower you or your firm to resurrect Axys.  As usual, I’ll be providing a level of information in this piece that may be more than you need to solve any immediate problem with the hope that info is useful to you in the future.

Axys Versions

There are two fundamental versions of Axys: the multi-user version and single-user version.  To add a little confusion, the multi-user version is frequently referred to as the network version, but both fundamental versions are regularly installed on networks.  So, the network version is a bit of a misnomer.  Among these two fundamental versions, there is also the version of the software, which is at this point typically version 3.8, 3.8.5, 3.8.6 or 3.8.7.  In addition to these, there are also Monocurrency, Multicurrency and Variable Rate versions, to name a few.  Suffice to say, there are a lot of different versions.

Axys Licensing Model

The concurrent licensing model that Axys implements applies to both single-user and multi-user versions.  In both instances, the number of real Axys users typically exceeds the total licensed users, but having a multi-user version allows more than one user to use Axys simultaneously and adds certain multi-user features, such as user-specific settings and separate blotters, et cetera.

Understanding How Axys is Installed

Initially, the single-user version is simpler to install because the primary program (Axys) and supporting programs (Dataport, Data Exchange, Report Writer, et al.) hypothetically only need to be installed once.  That would be true if there literally was only one user using the software on one PC.  In actuality, the single-user version of Axys and supporting programs get installed multiple times in a network environment. They need to be installed once for every user, albeit to the same destination for each user (e.g., F:\Axys3).

During the Axys install process, certain required files are copied to the user’s PC and/or profile and Axys creates registry keys in HKEY_CURRENT_USER\SOFTWARE\Advent.  The most critical Axys registry keys are stored in HKEY_CURRENT_USER\SOFTWARE\Advent\Axys\3.  Although there are several important Axys files, the firmwide.inf is perhaps the most crucial file.  In a single-user installation, this text file, which can be found in the root folder of Axys (e.g., F:\Axys3), details certain settings in use and where all of the other Axys files can be found.

The multi-user version must also be installed multiple times for users, but the initial Axys install varies.  You install it once to the network/primary destination folder (e.g., F:\Axys3) and then install it again for the rest of the users (e.g., F:\Axys3\users\kevin where a firmwide.inf file will be created).  Similar to the single-user version, the supporting programs such as Dataport, Data Exchange and Report Writer would also need to be installed if the user needs those, or if you are trying to make sure all of the users have access to all of the supporting apps. The same registry keys are used for the multi-user install as the single-user version, but the multi-user (a.k.a. network) version adds an additional critical file: the netwide.inf file.

Netwide.inf versus Firmwide.inf

These two files are closely related.  The netwide.inf file should only be found in the root Axys folder of a network install, but firmwide.inf files exist in both single-user and multi-user environments.  The multi-user version is designed to use the settings in the netwide.inf as the system default and have any settings in the firmwide.inf supersede the settings in the netwide.inf.  As a rule, you should never see a firmwide.inf in the root Axys folder of a network install.  You should also almost never see a netwide.inf file in the root of a single-user Axys installation.


A Recurring Axys Installation Bug

With regard to installing Axys, there is a rather annoying issue that has been going on for several years.  It seems that the Axys install will not recognize certain network locations and/or mapped drives.  The fix requires the following registry settings:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]

“EnableLUA”=dword:00000001

“EnableLinkedConnections”=dword:00000001

Once those settings have been applied, the Axys install program will be able to find the mapped drives.  It seems to me that this is an issue Advent should have addressed a long, long time ago.

Understanding Those Axys Shortcuts and Corresponding Registry Entries

The working folder of the Axys shortcut needs to point to the appropriate folder for the firmwide.inf file.  That means that an Axys shortcut for a single-user version of Axys should have a “Start in” folder like F:\Axys3, whereas the multi-user version would have “Start in” folder like F:\Axys3\users\kevin.  Assuming the same install folder was used, the target for these shortcuts would be the same: F:\Axys3\Axys32.exe.  Likewise, the registry entries associated with Axys should match these settings.  When I am looking at a system, I can usually determine if Axys has been installed properly by looking for consistency between the shortcuts and the following registry entries: ExePath, NetPath and UserPath.

In summary, your Axys install is dependent on a few things: the files themselves, access to the location where they are stored and proper mapping to the location of those files in the registry, firmwide.inf and netwide.inf if applicable.  Hopefully, you can get things back online on your own, but if you need assistance with your Advent installation, reach out to me and I’ll do my best to assist you.

Kevin Shea Impact 2010

About the Author: Kevin Shea is the Founder and Principal Consultant of Quartare; Quartare provides a wide variety of technology solutions to investment advisors nationwide.

For details, please visit Quartare.com, contact Kevin Shea via phone at 617-720-3400 x202 or e-mail at kshea@quartare.com.

Tags: , , , ,
Comment